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.