# OAuth on MCP is not the same as authorizing each tool call

> Source: <https://dev.to/authbyexample1/oauth-on-mcp-is-not-the-same-as-authorizing-each-tool-call-1j09>
> Published: 2026-09-24 13:40:21+00:00

OAuth on MCP answers “who is calling?” It does not, by itself, answer whether a particular `tools/call` should run.

The 2026-07-28 MCP spec tightens auth and routing with issuer validation, the CIMD direction, and `Mcp-Method` / `Mcp-Name` headers. Those are useful signals, but authentication is still only one decision: AuthN verifies who is calling; tool-call authorization asks whether this principal may run this tool, on this resource, in this context, right now.

That context matters for risk. A `read_ticket` should not necessarily get the same friction as `issue_refund`, and neither should be treated like `drop_table`. Use the method/name headers to help tier the request.

A practical pattern is `MCP client → gateway → PDP → MCP server`, with deny-by-default and step-up checks for high-risk operations.

We wrote about the distinction and the practical design in [our write-up](https://www.permit.io/blog/mcp-auth-vs-tool-call-authorization-2026-07-28).