Skills vs MCP: Is MCP Just an Auth Gateway Now?

Last Thursday, Simon Willison surfaced a quote from Sean Lynch that distilled a debate the agent community has been circling for months: “the real valuable capability MCP offers over skills/CLI is isolating the auth flow outside of the agent’s context window, and potentially out of the harness completely.” Lynch’s conclusion: “maybe the idealized form of MCP is just an auth gateway for the API and nothing else.”

That’s a provocation worth testing. MCP — the Model Context Protocol donated to the Linux Foundation’s AAIF in December 2025 — was supposed to be the USB-C of AI tooling. A universal connector. But six months into 2026, the skills paradigm has exploded past MCP in developer adoption, and benchmark data suggests MCP’s architecture imposes costs that skills simply don’t. The question isn’t whether MCP is useful — it’s what MCP is actually useful for.

The benchmark reality

Let’s start with numbers, not opinions. Scalekit ran 75 benchmark tests comparing MCP against CLI for identical GitHub tasks — checking repo language, pulling PR details, listing merged contributions. The results are stark:

Approach	Tokens (repo language task)	Monthly cost (10K ops)	Reliability
CLI	1,365	~$3.20	100% (25/25)
CLI + Skills	4,724	~$4.50	100% (25/25)
MCP (direct)	44,026	~$55.20	72% (18/25)

That’s a 32× token multiplier for MCP on a simple metadata query. A 17× cost multiplier at scale. And seven of 25 MCP runs failed to TCP-level timeouts connecting to GitHub’s Copilot MCP server — a 72% reliability rate versus CLI’s perfect 100%.

The pattern holds across tasks. PR details: 20× more tokens. Repo metadata: 9×. The cheapest MCP operation still costs 4× its CLI equivalent.

Dr. Prahlad G. Menon’s analysis identifies the root cause: schema injection. MCP loads every tool definition — names, descriptions, input schemas, output schemas — into the context window simultaneously, regardless of which tools the task actually needs. GitHub’s Copilot MCP server exposes 43 tools. Every conversation loads all 43 definitions, even when the agent uses one.

Skills work differently. A skill injects roughly 800 tokens of procedural knowledge — not tool schemas, but instructions about how to use the tools the agent already has access to. That guidance reduces tool calls by approximately one-third while maintaining 100% reliability. The cost difference isn’t marginal; it’s architectural.

Why skills won the adoption race

The skills paradigm didn’t win on theory. It won on developer behavior.

mattpocock/skills — Matt Pocock’s personal .claude/ directory, published as a public repository — sits at 139,000 stars as of this writing, with +1,441 stars per day on the current trend. That makes it one of the fastest-growing developer tools repositories in GitHub history, and it contains exactly zero lines of executable code. It’s 21 markdown files.

The signal is unmistakable: “Skills went from an Anthropic feature to a community standard with six-figure-star repos in one trending cycle.” The skills directory race between mattpocock/skills and Composio’s awesome-codex-skills validated that the pattern isn’t Claude-specific — it’s harness-agnostic.

On X, Boris Cherny (@bcherny) pushed the paradigm further: “I’ve been using Artifacts in Claude Code for everything: visual explanations of tricky code, system diagrams, quick previews of a few animation options, data analyses and dashboards I share with the team.” Skills aren’t just replacing MCP connections — they’re replacing entire categories of standalone tools.

The HN thread “Claude Skills are awesome, maybe a bigger deal than MCP” captured the practitioner consensus early. A follow-up post titled “You don’t need MCP. You need Claude Skills.” went further. The community was voting with stars and comments: skills were solving their immediate problems in ways MCP wasn’t.

But that doesn’t mean MCP is dead. It means MCP’s value proposition needs recalibrating.

What MCP is actually for

Here’s where Lynch’s provocation gets interesting. Look at what MCP is investing in for the July 2026 spec update, and you see a protocol leaning hard into exactly the capabilities Lynch identified.

The MCP 2026-07-28 Release Candidate introduces three changes that are architecturally significant:

1. Stateless transport: MCP servers can now run behind plain round-robin load balancers — no sticky sessions, no shared session stores. The protocol added Mcp-Method and Mcp-Name headers so gateways can route without inspecting request bodies.

2. Schema caching: ttlMs and cacheScope fields on list results (modeled on HTTP Cache-Control) let clients know exactly how long a tools/list response is fresh and whether it’s safe to share across users.

3. Server Cards: .well-known/mcp.json endpoints let registries, crawlers, and clients discover server capabilities without establishing a connection — autoconfiguration, security validation, and reduced latency.

Every one of these features makes MCP better at being a gateway — a registry and auth layer that sits between agents and APIs. None of them make MCP better at being a runtime — they don’t help the agent think about how to use the tools or reduce the per-task token cost.

The 2026 MCP Roadmap is even more telling. Its four priority areas: transport evolution, agent communication, governance, and enterprise readiness. “Stateful sessions fight with load balancers, horizontal scaling requires workarounds” is the problem statement. The solution is gateway infrastructure.

WorkOS’s analysis of the spec update focuses almost entirely on authentication: OAuth flows, API key management, multi-tenant access control. MCP’s roadmap is converging on Lynch’s prediction — whether or not the MCP team would frame it that way.

Progressive discovery: closing the gap

To be fair, MCP hasn’t ignored the token problem.

In January 2026, Anthropic shipped progressive discovery — a mechanism that loads tool schemas on demand rather than injecting them all at session start. According to Dr. Menon’s data, this reduced MCP’s token overhead by 85%, from 77,000 tokens to 8,700 tokens for a server with 50+ tools.

That’s a dramatic improvement. But 8,700 tokens is still 10× more than the ~800 tokens a skill injects. And progressive discovery doesn’t address reliability — the TCP timeouts in Scalekit’s benchmarks aren’t schema-related. They’re connection-management issues that live at the transport layer, and the stateless transport changes in the July spec are the actual fix for those.

The gap is narrowing. But it’s narrowing because MCP is evolving toward what skills already do efficiently — not because MCP has found a way to make universal schema injection cheap.

The three-layer architecture

The practitioner consensus on HN — “Claude Code as a Daily Driver” — settled on a hybrid model. Not skills OR MCP, but skills AND MCP, each handling what it handles best.

One analysis articulated the three-layer mental model most clearly:

• MCP is the registry layer — what tools exist, how to authenticate, what schemas they expose.
• CLI is the execution layer — fast, reliable, token-efficient task execution.
• Skills are the orchestration layer — procedural knowledge about how to combine tools, when to use which approach, and what the domain-specific workflow looks like.

This layering explains why MCP’s value concentrates at the auth boundary. MCP doesn’t need to be the fastest or most efficient way to call gh pr list — CLI handles that. MCP needs to be the most reliable way to discover that gh pr list exists, authenticate the user to GitHub, and expose the capability to agents that don’t have CLI access.

IntuitionLabs’ technical comparison frames it as: “Skills embed procedural/organizational knowledge while MCP provides standardized connectivity — they’re complementary, with MCP reaching data and services while Skills interpret, validate, and act on that data in domain-correct ways.”

That’s the answer to Lynch’s provocation. MCP isn’t just an auth gateway. But auth and discovery are its highest-value contributions — the capabilities that skills genuinely can’t replicate.

The real-world decision matrix

Before the abstract architecture, here’s the practical question: when should you use which?

Scenario	Best approach	Why
Solo dev, own machine	CLI + Skills	Zero overhead, 100% reliability, ~800 tokens
Team workflow standardization	Skills (shared repo)	mattpocock/skills pattern — markdown is version-controllable, reviewable, forkable
Connecting to third-party SaaS	MCP	Auth isolation, credential scoping, service discovery
Multi-tenant B2B product	MCP (required)	Your agent touches customer data across organizational boundaries
Agentic pipeline (5+ tools)	Skills wrapping MCP	Skills orchestrate the workflow; MCP handles the authenticated API calls
Air-gapped / on-prem	CLI only	No external protocol needed

The hybrid “skills wrapping MCP” pattern deserves special attention. In practice, this means a skill file that contains instructions like “use the GitHub MCP server to authenticate, then run gh pr list via CLI for the actual query.” The skill provides the procedural knowledge; MCP provides the credential boundary; CLI provides the execution speed. Each layer does what it does best.

Firecrawl’s decision guide reaches the same conclusion from the tool-builder’s perspective: “If you’re building a personal developer tool, CLI+Skills is the obvious choice. If you’re building B2B SaaS, MCP’s authorization boundaries are valuable.”

When MCP wins anyway

If you’re building a personal development workflow — your terminal, your repos, your tools — CLI + Skills is the obvious choice. You control the environment. You have shell access. You don’t need a protocol layer to authenticate yourself to your own machine.

But change the context to B2B SaaS, and the calculus flips:

Multi-tenant authorization. Your agent acts as your customer’s employee, inside your customer’s organization, touching your customer’s data. The auth boundary MCP provides isn’t a convenience — it’s an architectural requirement. You can’t give an agent a CLI and an API key and let it figure out which customer’s Slack workspace to post in.

Enterprise access control. SSO integration, audit trails, gateway behavior, configuration portability — the MCP roadmap’s entire “enterprise readiness” priority exists because skills can’t solve organizational access control.

Cross-vendor discovery. When your agent needs to find and connect to tools it hasn’t seen before — a new Slack integration, a customer’s custom API — MCP’s Server Cards and .well-known endpoints provide machine-readable discovery that no amount of markdown instructions can replicate.

The supply chain risks are also worth noting: skills downloaded from public repositories carry the same trust problems as npm packages. MCP servers, with their OAuth scoping and gateway architecture, provide at least a structural separation between “what the skill knows how to do” and “what credentials it has access to.”

The verdict: directionally right, strategically wrong

Sean Lynch is directionally right. MCP’s highest-value contribution is auth isolation. The token compression tooling emerging around MCP confirms that the protocol’s schema-injection model is a recognized cost center. Progressive discovery was an 85% reduction, but it was also an admission that the original architecture over-served.

But “just an auth gateway” undersells what auth isolation enables at scale:

1. Multi-tenant agents — impossible without MCP’s boundary separation
2. Machine-readable discovery — Server Cards create a browsable internet of agent capabilities
3. Credential delegation — separating “what the agent can do” from “what the agent knows” is a security architecture, not just a convenience

The skills paradigm won the developer adoption race because it solved the immediate problem — making agents useful for individual developers — with minimal overhead. MCP will win the enterprise infrastructure race because it solves the harder problem — making agents trustworthy across organizational boundaries.

The smart play in 2026 isn’t choosing sides. It’s recognizing that you’re looking at three layers of a single stack:

• Skills tell the agent what to do — procedural knowledge, workflow discipline, domain expertise.
• MCP tells the agent what it can reach — authenticated APIs, discovered tools, scoped credentials.
• CLI tells the agent how to execute — fast, reliable, token-efficient commands.

The harness substrates debate is already converging on this architecture. mattpocock/skills at 139k stars tells you where the energy is. The MCP July spec tells you where the infrastructure is heading. And Lynch’s quote tells you the architectural truth that both camps would rather not state clearly: MCP is most valuable precisely when it does least.

The gateway isn’t a demotion. It’s a promotion to the role MCP was always best suited for.