OAuth checks

When your MCP server needs sign-in, MCP Tower signs in to it the way an agent does. It reads the same discovery documents, registers the same way, asks for the same scopes and sends the token back to your server. Each step is a check, and the scan reports the first place where the flow breaks, what to change and a link to the page that explains it. Every page shows the exact message the check produced, the fix, and a curl command you can run to confirm the fix before you scan again.

Diagnostics appear only when OAuth is involved: your server answered with a 401 or 403, a signed-in scan used a token, or a tool needs or may need sign-in. A server that is open to everyone shows no OAuth checks at all.

The checks follow the order in which an agent signs in. A failure early in the flow means the later steps never run.

Discovery. The agent finds out where to sign in: 401 challenge, protected resource metadata, resource identifier, authorization servers and authorization server metadata.
Authorization server capabilities. The agent checks that it can use the authorization server: endpoints, PKCE and client identity.
Sign-in. The agent registers, sends the user to sign in and gets a token: client registration, authorization, token exchange, token accepted and token refresh.
Tool readiness. The agent learns which tools need sign-in and what they need: tool scopes, declared schemes, hidden tools and call-time responses.
Behind MCP Tower. Tokens work for the hostname agents use: public audience.

All checks

The name in the second column is the one the app shows in its checklist.

#	Check	In the app	What it verifies	Results
1	`challenge`	401 challenge	An unauthenticated request gets `401` with `WWW-Authenticate: Bearer` and `resource_metadata`	pass, warn, fail, skip
2	`resource_metadata`	Protected resource metadata	The protected resource metadata document is found and is valid JSON	pass, fail
3	`resource_matches`	Resource matches the endpoint	The metadata’s `resource` is the URL agents connect to	pass, fail, skip
4	`authorization_servers`	Authorization server listed	The metadata lists an authorization server in `authorization_servers`	pass, fail, skip
5	`server_metadata`	Authorization server metadata	The authorization server publishes metadata whose `issuer` is the listed URL	pass, fail, skip
6	`endpoints`	Authorization and token endpoints	`authorization_endpoint` and `token_endpoint` are present and use `https`	pass, fail, skip
7	`pkce`	PKCE with S256	`code_challenge_methods_supported` includes `S256`	pass, fail, skip
8	`client_identity`	Client registration offered	Agents can identify themselves with a Client ID Metadata Document or register with Dynamic Client Registration	pass, warn, skip
9	`registration`	Client registration	Dynamic Client Registration, when used, succeeds	pass, fail, skip
10	`authorization`	Authorization response	The sign-in callback carries a code, no `error`, and the right `iss`	pass, fail, skip
11	`token_exchange`	Token exchange	The token endpoint returns a Bearer access token for the code	pass, fail, skip
12	`token_accepted`	Token accepted by the server	Your MCP server accepts the new token for discovery and `tools/list`	pass, fail, skip
13	`token_refresh`	Token refresh	An expired access token can be refreshed	pass, fail, skip
14	`tool_scopes`	Tool scopes granted	The token holds every scope the protected tools declare	pass, warn, skip
15	`declared_schemes`	Tools declare their sign-in	Every tool that needs sign-in declares `securitySchemes`, with no conflicting declarations	pass, warn, skip
16	`hidden_tools`	Tools listed before sign-in	No tool appears only after sign-in	pass, warn, skip
17	`call_time_guidance`	What happens when a tool is called	What a protected tool must return when it is called without a token or without enough scope	info, skip
18	`public_audience`	Tokens for the public hostname	The `resource` names the public hostname agents use, not your origin host	pass, warn, skip

“skip” stands for skipped.

What the results mean

Status	Meaning
pass	This step works the way agents expect.
info	Something MCP Tower cannot verify from a scan, with what your server must do. Only the call-time check gives this result.
warn	Sign-in still works for some agents, but users of others will be blocked or see a worse experience. Fix it before you rely on the server.
fail	Agents cannot complete sign-in at this step. The checks that depend on it are skipped.
skipped	The check did not run. The app says why: an earlier check failed, the check needs a signed-in scan, or it runs only while someone signs in.

Every warning and failure comes with a next step and a link to its page. A check is skipped for one of these reasons:

An earlier check failed. Discovery stops at the first missing piece, and every later discovery check says what it needed: “Needs the protected resource metadata.”, “Needs an authorization server.”, “Needs the authorization server metadata.” or “Needs valid authorization server metadata.”
It runs only during sign-in. Client registration, authorization and token exchange happen while someone signs in. In a scan they show “Checked when someone signs in.” The result of the latest sign-in attempt appears on the server’s page.
It needs a token. The token and tool checks need a scan that runs as a signed-in user. Select Sign in to scan to get one.
Nothing to check. For example, no tool needs sign-in. A check that has no other result shows “Not applicable.”

After you change your server or your authorization server, select Scan again on the server’s page. The scan runs every check again and replaces the checklist. Most pages end with a “Check it yourself” command, so you can confirm a fix first.

Copy report puts the scan on your clipboard as plain text, for the person who runs the authorization server. It holds the origin URL, the result, each check with its status, message, next step and docs link, and the HTTP steps of the scan: method, URL, status code and time. It never contains tokens, authorization codes, secrets or response bodies, so you can paste it into a ticket or a chat.

Glossary

Protected resource

Your MCP server, as OAuth sees it: a server that accepts access tokens. It describes itself in a protected resource metadata document (RFC 9728) at /.well-known/oauth-protected-resource.

Resource identifier

The resource value in that document: the exact URL agents connect to, such as https://mcp.example.com/mcp. Agents send it to the authorization server (RFC 8707), so tokens are issued for that URL.

Authorization server

The server that signs users in and issues tokens, such as https://auth.example.com. It can be your own service or an identity provider. It describes itself in authorization server metadata (RFC 8414 or OpenID Connect Discovery).

Issuer

The authorization server’s identifier, an https URL. It appears in authorization_servers, in the issuer field of its metadata and in the iss parameter of sign-in responses, and all three must be the same string.

Scope

A named permission, such as files:read, that a token grants. Your server can ask for scopes in its 401 challenge, and each tool can declare the scopes it needs.

PKCE

Proof Key for Code Exchange (RFC 7636). The agent sends a hashed secret when the user signs in and the secret itself when it exchanges the code, so a stolen code is useless. MCP requires the S256 method.

CIMD

Client ID Metadata Document. The agent’s client id is an https URL that serves a JSON document describing the agent, so the authorization server needs no registration step. MCP recommends it.

DCR

Dynamic Client Registration (RFC 7591). The agent registers itself at the authorization server’s registration_endpoint and gets a client id. MCP 2026-07-28 deprecates it in favor of CIMD.

Step-up

Asking for more scope later. When a signed-in user calls a tool that needs a scope the token lacks, the server answers 403 with error="insufficient_scope" and the scopes it needs, and the agent signs the user in again with them.