OAuth on MCP proves who is calling, not what each tool call may do

The distinction at the heart of the post

A post on dev.to draws a line that is easy to blur when securing a Model Context Protocol deployment: OAuth establishes who is on the other end of the connection, and nothing more. Whether a specific tools/call request should actually execute is a separate decision that an access token, on its own, never makes.

The author frames this as two different questions. Authentication resolves the caller's identity. Tool-call authorization must decide something far more situational: whether this particular principal is permitted to run this particular tool, against this resource, under these conditions, at this moment. A token that was sufficient to open the session says nothing about any of those variables.

What the 2026 spec changes, and what it leaves open

According to the post, the MCP specification revision dated 2026-07-28 tightens the protocol's authentication and routing behavior in several ways, including issuer validation, the CIMD direction, and new Mcp-Method and Mcp-Name headers. These are meaningful additions. The headers in particular surface which method and which tool a request targets, handing policy layers something concrete to inspect instead of an opaque request.

The central claim, though, is that all of this remains at the authentication and routing layer. It confirms who is calling and helps steer the request to the right place; it does not determine whether the request ought to run. That judgment is left entirely to what a builder constructs around the protocol.

Not every tool call deserves the same friction

The author uses a simple risk spectrum to make the point. A read_ticket lookup is low-stakes and should pass with minimal ceremony. An issue_refund call moves money and deserves more scrutiny. A drop_table operation is destructive and warrants the highest bar of all. Treating the three identically, which is effectively the default if you rely on OAuth alone, is either reckless for the dangerous calls or needlessly slow for the harmless ones.

The suggested mechanism for tiering is the new headers: read Mcp-Method and Mcp-Name, classify the incoming request by risk, and route it through the appropriate amount of checking.

A pattern for enforcing per-call decisions

For the enforcement layer itself, the post sketches a pipeline running from MCP client to gateway to PDP to MCP server. The gateway sits between the client and the tool server; the PDP, a policy decision point, evaluates each request against the rules; and the server only executes what the pipeline approves.

Two principles anchor the design. First, deny by default: a request is refused unless policy explicitly allows it. Second, apply step-up checks for high-risk operations, so that a sensitive tool call demands stronger assurance than an ordinary session token provides.

Why it matters

Agent integrations multiply the number of privileged operations a single connection can trigger, and a model's choice of tool is not something a human reviews in advance. Under those conditions, session-level authentication is a floor, not a ceiling. It tells you the actor is legitimate, but not that every action the actor's agent attempts is wise or intended.

The post is a useful corrective for builders who assume that wiring OAuth into an MCP server means authorization is finished. The headers introduced in the 2026-07-28 revision make fine-grained decisions easier to implement, and the client-to-gateway-to-PDP-to-server pattern offers a concrete way to act on them. Anyone exposing tools with differing sensitivity, from harmless reads to financial operations to destructive writes, will need exactly this kind of split between letting a caller in and letting a call through.