# MCP vs Agent Skills: What the 2026 Spec Change Finally Settled for Me > Source: > Published: 2026-08-02 16:07:23+00:00 I spent a week thinking about this wrong. When Anthropic’s Agent Skills started showing up in the same conversations as Model Context Protocol, I fell into the obvious trap: assuming one was meant to replace the other. I searched “MCP vs Skills,” read forum threads, opened GitHub issues. Somewhere in that process I convinced myself this was a competition I needed to pick a side in. Then the July 28, 2026 MCP specification shipped, and the framing I had been using fell apart on its own. Every MCP spec revision since November 2025 arrived as a release candidate first. The 2026–07–28 revision, the largest change to Model Context Protocol since its 2024 debut, ran as a release candidate for ten weeks. On July 28, it stopped being a draft. That distinction matters more than it sounds. Every piece of analysis published before that date carried an implicit asterisk: “as of this writing, before the spec locked.” That asterisk is gone. The four Tier 1 SDKs, TypeScript, Python, Go, and C#, all shipped speaking the new spec on day one. Rust followed in beta. The adoption numbers that landed alongside the announcement are hard to ignore: close to half a billion downloads a month across those four SDKs, with both TypeScript and Python individually crossing one billion total downloads. This is not a protocol anyone is still evaluating. Production systems you depend on almost certainly run on it already. State still exists when you need it, but it is now an explicit handle the client passes back as an argument, the same pattern ordinary HTTP APIs have used for years, rather than something buried in session storage a server has to maintain. The reaction from teams actually running this in production was worth paying attention to. AWS said this enabled long-lived agent work without session management overhead in Amazon Bedrock AgentCore. Cloudflare confirmed its Agents SDK supports the spec from day one. Microsoft Foundry said the stateless core is what let it scale from dozens of integrations to thousands through a single endpoint. Manufact described the session-state removal as ending the infrastructure workarounds it had been building just to handle production traffic. That last one named something I recognized: the scaffolding you build not because you want to, but because the protocol gives you no other option. MCP is a connection protocol. It defines how an agent reaches outside the model to talk to a database, call an API, or read from a file system. It handles transport, authorization, and tool semantics. Agent Skills are a knowledge format. A Skill is a folder of instructions, scripts, and examples that teaches an agent how to approach a category of work. Anthropic launched Skills in October 2025 and published them as an open, cross-platform standard in December 2025. That cross-platform part matters: Skills written in the SKILL.md format run on any compatible client, not just Claude. The analogy that clicked for me: a Skill is like an onboarding document for a new hire. It explains the workflow, which tools to reach for, and in what order. The MCP connection is the door badge that lets the hire actually access the systems the document describes. Remove the document and the hire has to rediscover the workflow every time. Take away the badge and the document becomes useless. Anthropic said directly in the Skills announcement that they plan to explore how Skills can complement MCP servers, not replace them. A well-designed MCP server can ship its own Skill alongside its tool definitions, so usage guidance travels with the server rather than living separately in every client that connects to it. Some gateway implementations, including [MCP360](https://mcp360.ai/), already apply this pattern, exposing a catalog of 100+ tools behind a search_tools and execute_tool interface so agents load only what they need rather than injecting every tool definition into context upfront. The clearest evidence these two layers solve different problems is in Anthropic’s own numbers. In a November 2025 engineering post on code execution with MCP, Anthropic described agents connected to dozens of MCP servers processing hundreds of thousands of tokens before reading a single user request. The fix was progressive discovery: instead of loading every tool definition into context upfront, the agent explores a filesystem of available tools and writes code that calls only what it needs. On one real workflow, that pattern cut token usage from 150,000 to 2,000. A 98.7 percent reduction. A separate test on a five-server, 58-tool setup found that loading all definitions upfront consumed roughly 55,000 tokens before any actual work began. Letting the agent search for relevant tools on demand brought that down by 85 percent, and pushed tool selection accuracy on Opus 4 from 49 percent to 74 percent. Skills help here too. A Skill can tell an agent which tools to reach for and in what order, shrinking the search space. But Skills and progressive discovery are additive improvements to the same underlying problem, not alternatives to each other. An agent with no MCP connection and a well-written Skill still cannot touch the database. An agent with a solid MCP connection and no usage guidance still burns tokens relearning the same workflow at the start of every session. That is the failure mode most teams hit before they understand both layers are load-bearing. One piece of the spec stayed genuinely ambiguous through the release candidate period: the fate of Dynamic Client Registration. The RC had signaled a move toward Client ID Metadata Documents (CIMD), but whether DCR would be formally deprecated or simply extended was not confirmed. The July 28 announcement settled it. DCR is deprecated in favor of CIMD, still working for backward compatibility with authorization servers that have not added CIMD support yet, but removal is coming in a future spec version. The practical difference: under DCR, a client registers itself with an authorization server at connection time and receives credentials back. Under CIMD, the client publishes a metadata document at a URL it controls, and the authorization server fetches that document to verify identity. Fewer moving parts during registration, and the identity claim is harder to spoof because the metadata lives at a domain the client actually owns rather than in a registration response that can be replayed. This change landed alongside RFC 9207 issuer validation and authorization hardening guidance from NSA and CISA. CIMD was the one piece of that picture that was not confirmed when the release candidate came out, which makes it the specific thing to act on if authorization is part of your deployment. Nothing about July 28 demands an emergency migration. What changed is the nature of the deadline. Before July 28, auditing for session dependencies was preparation for a draft that could still shift. After July 28, it is preparation for a spec that will not. The four SDKs are already there. The beta branches you were treating as a moving target are now the stable release. **If you host your own MCP servers:** the session dependency audit and deprecated feature review belong on your sprint backlog. The error code change in the spec breaks handlers silently if they still match the old value, and that is worth catching before a downstream failure surfaces it. **If you route through a managed gateway:** most of the transport migration is likely already handled for you. Confirming your provider’s support timeline before it becomes urgent is worth an afternoon. MCP360 published their [migration checklist](https://mcp360.ai/blog/migrating-to-stateless-mcp) alongside the spec announcement if you need a reference point for what to verify. **If you built against the experimental Tasks API from November 2025:** plan a full migration rather than a patch. The lifecycle states changed, not just surface-level details. **If you only use MCP through a client like Claude or Cursor:** nothing changes in your day-to-day work. The twelve-month deprecation window on Roots, Sampling, and Logging is the next date worth watching. Those features still work today, but the countdown started July 28, and SDK changelogs over the next year will signal where the ecosystem is heading before any removal date arrives. The question that interests me more than any of that: whether progressive discovery becomes the default architecture for agents working across large tool catalogs, or stays a fix teams reach for after the first billing shock. Anthropic ships it as a first-class pattern in Claude Code and the API’s Tool Search Tool. MCP gateways applying the same search-first approach to tool catalogs were already doing this before Skills existed. The pattern is not new. What is still open is whether server authors build for it from day one, or treat it the way most teams treat caching: an optimization you add after the cost problem becomes undeniable. Skills becoming a cross-platform open standard in December 2025 raised the stakes on that. Once multiple clients read the same SKILL.md format, a Skill built once becomes a shared layer for several agents, and none of them stop needing MCP to reach outside the model. The framing that holds up now is not which one wins. It is which layer handles which job, and whether you have both in place before the workflow breaks and you have to figure it out under pressure. *Based on the MCP 2026–07–28 specification announcement and Anthropic engineering posts from November 2025. Spec and SDK changelogs are the authoritative source for migration specifics.* [MCP vs Agent Skills: What the 2026 Spec Change Finally Settled for Me](https://pub.towardsai.net/mcp-vs-agent-skills-what-the-2026-spec-change-finally-settled-for-me-9972d7456fba) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.