MCP Is the OAuth Layer
There was a stretch where every other post on my timeline was some variation of “MCP is overengineered, just use skills.” I get the impulse. The protocol has rough edges. The ecosystem is noisy. Running a server feels like ceremony when you could just ship a tool definition in your system prompt.
But I keep noticing something about the people making this argument. They’re almost always building for one user. Themselves. Their personal agent. Their local setup. And when you’re the only user, sure, skills are fine. Bake in your tokens. Hardcode your access. Ship it.
The moment you have a second user, the argument falls apart.
The Single-User Trap
Skills, as they exist in the various agent frameworks, are a tool definition plus some code. They execute in the context of whoever is running them. If that’s you, the credentials are yours. Your Google token. Your GitHub PAT. Your database connection string. Whatever your skill needs, you give it, because you are the user and the developer and the operator all at once.
Now imagine shipping that to a hundred users. Each one has their own Google account. Their own GitHub. Their own data. You can’t hardcode anything. You need a flow for each user to authorize your agent to access their data on a third-party service.
This is not a new problem. This is the problem OAuth solved fifteen years ago for web apps. We are re-learning it for agents, and some people are going to re-learn it the hard way.
What MCP Actually Is at This Layer
Strip away the tool-calling interface for a moment. Ignore the JSON-RPC. Ignore the stdio transport. Look at what the 2025 MCP spec does for authorization1 and it’s almost boring in how conventional it is.
An MCP server is a Resource Server in OAuth terms. It hosts protected tools and data. It validates bearer tokens. It does not issue them.
An Authorization Server, separate from the MCP server, handles login, consent, and token issuance.2 This separation is standard OAuth 2.1 practice. The resource doesn’t know your password. It only knows how to verify a token.
A client, your agent, hits the MCP server. If it has no token, it gets a 401 with a WWW-Authenticate header pointing to discovery metadata. It follows RFC 9728 (Protected Resource Metadata) to find out which authorization server governs this resource.3 It runs an Authorization Code flow with PKCE.4 The user consents. The agent gets a token scoped to that specific resource via RFC 8707. It presents the token. The MCP server validates it and serves the request.
That’s it. That’s the layer. It is exactly what you would design if you sat down to solve “how do I let an agent access user data on a third-party service” and you had any familiarity with how the web works.
”But Skills Can Do Auth Too”
Sure. You can bolt OAuth onto a skill. Store per-user tokens in your backend. Handle refresh flows. Manage consent screens. Route each tool invocation through middleware that looks up the calling user, finds their token for the target service, and makes the request on their behalf. Handle token expiration. Handle revocation. Handle the case where the user changed their password and all your refresh tokens are now invalid. Build a dashboard so users can see what your agent is connected to. Build a revoke button. Build audit logs because someone’s compliance team is going to ask.
Congratulations. You just built an MCP server. You gave it a different name.
This is the part that gets me. The skills-only crowd isn’t arguing against the architecture MCP describes. They’re arguing against the label. The moment your skill needs to access a user’s data on a remote service, you need a way to discover what auth is required, a way to initiate an OAuth flow per-user, a way to store and refresh tokens, a way to scope access, a way to revoke. That is a protocol. You can invent your own or you can use the one that already exists and that every serious tool provider is converging on.5
Every sufficiently advanced skill with multi-user auth is an ad-hoc, informally-specified, bug-ridden implementation of half of MCP.6
The Composability Argument
Even if you enjoy reinventing OAuth flows, the proprietary approach has a second problem. It doesn’t compose.
Without a protocol, every tool integration is bespoke. You build the Google auth flow for your agent. Then the Slack flow. Then GitHub. Then Notion. Each one is its own dance. Each one has its own failure modes. Each one needs its own dashboard UI. And none of this work transfers to the next agent your team builds.
With a protocol, tool servers are interchangeable. You connect a new MCP server and your agent discovers it, the auth flow is standardized, the token exchange is standardized, the user consent experience is consistent. The tool server’s author handled the integration with their service. You handle the integration with the protocol. Once.
This is the same reason we have HTTP instead of each website inventing its own wire format. Boring convergence on a shared protocol is how infrastructure gets built.
Where I’ll Concede Ground
MCP’s tool-calling interface is not obviously better than the native function calling offered by OpenAI or Anthropic. For local tools, running in-process, with no remote authorization concerns, skills and function definitions are lighter, faster, and tighter. I will not die on the hill of “use MCP for everything.”
MCP’s value is specific. It is the remote, multi-user, authorized access pattern. That is a pattern skills cannot replicate without becoming MCP servers wearing a costume.
The Question to Ask
When someone tells you MCP is unnecessary, ask them one question. How does a user of your product authorize your agent to access their data on a third-party service?
If the answer involves OAuth in any form, they are describing MCP, whether they know it or not. If the answer doesn’t involve OAuth, they don’t have multiple users, or they’re about to have a very bad security incident.
This is not a debate about protocols. It is a debate about whether you’ve ever shipped something to more than one person.
Footnotes
-
Aaron Parecki, Let’s Fix OAuth in MCP ↩
-
MCPJam, The MCP Authentication Checklist (November 2025 Spec) ↩
-
GitGuardian, OAuth for MCP: Emerging Enterprise Patterns for Agent Authorization ↩
-
With apologies to Greenspun. ↩