01 / The difference
Two facts that must stay separate
A client obtains a token for a finance MCP server, then requests a payment tool with a new beneficiary.
MCP HTTP authorization uses OAuth-related discovery and tokens to authenticate and authorize access to protected resources. A valid token alone does not approve every tool invocation or downstream effect.
Validate issuer, audience, expiry and resource context at the server; separately evaluate the payment action and arguments at execution.
- 01Client / task
- 02MCP server
- 03Tool call + arguments
- 04Downstream effect
02 / Decision boundary
Put the check where it can stop the effect.
Validate issuer, audience, expiry and resource context at the server; separately evaluate the payment action and arguments at execution.
Architecture review / negative test
Make the boundary testable.
For HTTP transport, map the client, protected resource, authorization server and downstream API as different roles. The MCP authorization specification describes resource metadata and audience-aware tokens; a local stdio deployment has a different trust boundary. Avoid claiming that a token issued for the MCP server is a business approval for all tools.
03 / Failure and evidence
What goes wrong, and what can be proven?
A valid token for the wrong resource is accepted or a broad scope becomes a blanket approval.
Log the client principal and token audience with the per-tool decision without exposing token material.
04 / Canonical scope
Why this reference stands alone
The existing MCP authorization solution explains the product problem; this reference owns transport authentication and the separate action boundary.
Architecture field test
Validate the resource token before tool policy
Which server is this token for?
- 01Discover protected resource metadata
- 02Obtain resource-bound token
- 03Validate issuer, expiry and audience
- 04Apply tool policy separately
Work the boundary
A client requests a token with resource=https://mcp.example.com/payments. That token may reach the payments MCP server. The server must not pass it unchanged to a bank API with a different audience.
| Required facts | Canonical resource URI, issuer metadata, token validity, client identity and distinct downstream credential. |
|---|---|
| Allow only when | The token was issued for this MCP resource and passes validation; tool access remains subject to separate policy. |
| Deny when | A token for server A is accepted by server B or forwarded to a downstream API. |
Break the assumption
Swap authorization-server issuer during callback, send a wrong-audience token and then attempt token passthrough to the bank API. Reject each at the appropriate boundary.
Design tradeoff
The July 2026 specification also addresses issuer validation and client registration changes. Keep protocol conformance distinct from business permission to execute a listed tool.
For validate the resource token before tool policy, consult MCP authorization specification, July 2026. This worked decision and negative test are ProofGrid analysis.
Continue with MCP tool authorization.
Primary references