MCP vs Agent Skills: What the 2026-07-28 Spec Actually Changes

---

MCP 2026-07-28 Spec: What’s New and Why It Matters

The official announcement confirms what the release candidate promised back in May. Across the four Tier 1 SDKs, MCP maintainers reported close to half a billion downloads a month, with both the TypeScript and Python SDKs individually passing 1 billion total downloads. Those numbers describe a protocol that a lot of production systems, quite possibly including yours, already depend on, not an experiment still waiting for validation.

Production Adoption Is Already at Scale

Reactions published alongside the spec read less like a press release and more like a status report from the infrastructure teams actually running it:

• AWS pointed to Tasks landing in Amazon Bedrock AgentCore as a way to run long-lived agent work without managing sessions.
• Cloudflare confirmed its Agents SDK supports the spec from day one, letting servers run in Workers without transport-session overhead.
• Microsoft Foundry framed the stateless core as what let it scale from dozens of integrations to thousands through a single toolbox endpoint.
• Manufact cited the removal of session state as ending the impractical infrastructure workarounds it had been building around to handle production traffic.
• Google Cloud framed the same shift as removing the friction of deploying agentic workflows at scale.

The Release Candidate Is Now Official

None of that reaction is new information about the mechanics. What’s new is confirmation. Every post written before July 28, including ours, hedged everything with “as of this writing” and a spec that could still change before it locked. That hedge is gone now. The four Tier 1 SDKs, TypeScript, Python, Go, and C#, all speak 2026-07-28 as of the ship date, with the Rust SDK following in beta.

---

MCP vs Agent Skills: How Their Roles Differ

Agent Skills Handle Workflows, Not Tool Access

The two threads meet here, and if you’ve been asking whether Skills quietly replace MCP servers, this is the section that answers it directly. Agent Skills arrived as organized folders of instructions, scripts, and resources that Claude loads dynamically, first announced October 16, 2025, and published as an open, cross-platform standard on December 18, 2025. MCP launched a year earlier as a protocol for connecting agents to external tools and data. A Skill packages instructions, examples, and scripts that teach an agent how to approach a task, the same way an onboarding document teaches a new hire a company’s specific workflow. Building one for a coding agent works the same way whether it’s a Skill for Claude Code or a Skill written for a different client. What a Skill doesn’t do on its own is reach outside the model. MCP handles that part, connecting an agent to a database, an API, or a file system it couldn’t otherwise touch.

Why Progressive Discovery Reduces Token Costs

Anthropic’s own numbers explain why both exist:

• Code execution with MCP: In a November 2025 engineering post, Anthropic described agents connected to dozens of MCP servers needing to process hundreds of thousands of tokens before reading a request. Instead of loading every tool definition into context, the agent explores a filesystem of available tools and writes code that calls only what it needs. Applied to a real workflow, that pattern cut token usage from 150,000 to 2,000, a 98.7 percent reduction.
  
• The Tool Search Tool: In Anthropic’s November 2025 rollout of advanced tool use, a five-server setup exposing 58 tools consumed roughly 55,000 tokens before any work began. Letting Claude search for relevant tools on demand instead of loading all of them upfront brought that down by 85 percent, and also raised MCP evaluation accuracy, with Opus 4 improving from 49 to 74 percent on tool selection tasks.

Every added tool call is a real cost line, part of the same economics that are reshaping how teams budget for agent usage as model pricing and tool-call volume both shift.

How MCP360 Uses Progressive Tool Discovery

Search first, load only what’s needed, is not a hypothetical pattern here. It’s the same shape as MCP360’s unified gateway, where search_tools and execute_tool expose a catalog of 100+ tools behind one integration without injecting every tool definition into context up front. Progressive discovery isn’t a Skills-only idea. It’s a pattern MCP gateways were already applying to the tool-sprawl problem before Skills existed, for the same reason Anthropic applied it inside Claude itself.

Skills and MCP Work Better Together

Anthropic said as much directly in the same Agent Skills announcement, stating it would explore how Skills can complement MCP servers by teaching agents more complex workflows involving external tools. A Skill can tell an agent which MCP tool to call and in what order, and a well-designed MCP server can ship its own Skill alongside its tool definitions so usage guidance travels with the server instead of living separately in every client that connects to it.

Choose the Right Layer, Not One Over the Other

The “vs” in most search queries assumes a team has to choose one. We think that framing is off. The real decision is architectural, not either-or:

• MCP is the layer that handles how an agent executes and coordinates work across external tools, covering authorization, transport, and tool semantics.
• Skills are the knowledge layer, telling an agent how to use what MCP already connected it to.

Drop MCP from the stack and the agent loses tool access. Drop Skills and it loses the procedural shortcuts that keep it from relearning a workflow every session. Whichever one you’re evaluating first, ask what job it’s doing before you ask which one wins.

---

Stateless MCP: Core Changes in the 2026-07-28 Spec

The architecture question is settled. What shipped on July 28 in the protocol itself mostly matches the release candidate.

Sessions and the Handshake Are Gone

The headline mechanic hasn’t changed since the release candidate:

• Sessions and the initialize handshake are gone. Protocol version and client identity now travel in _meta on every request instead of getting negotiated once at connection time.
• Any server instance can answer any call. Nothing about a request depends on which backend handled the one before it, so a load balancer can route on plain round-robin.
• State becomes an explicit handle, not a hidden session. If a server needs to remember something across calls, it mints a handle and the client passes it back as an argument, the same pattern ordinary HTTP APIs have used for years.

How a gateway routes stateless requests across dozens of connected servers shows the operational payoff directly, since a single routing layer no longer has to reconcile session state for every backend behind it.

Tasks and MCP Apps Ship as Designed

Tasks, MCP Apps, and the formal Extensions framework also shipped as described in the release candidate. Tasks now lives in its own io.modelcontextprotocol/tasks extension instead of the core protocol, with a poll-based lifecycle replacing the old blocking calls. The lifecycle states and client support matrix behind Tasks, Apps, and the wider Extensions framework haven’t changed between May and July.

Migration Checklist for MCP Server Authors

The mechanics above haven’t moved since May. Confidence has. What’s worth running against your production servers now, not just a beta branch:

• The specific error code change and the literal string it breaks silently if a handler still matches the old value.
• The new Tasks lifecycle, since anything built on the experimental 2025-11-25 API needs a real port, not a patch.
• SDK pinning commands for whichever language the server runs, covered in full in the server-author migration checklist.
• A test run behind a plain round-robin load balancer, still the fastest way to surface a hidden session dependency and the same diagnostic behind most MCP server connection issues that turn out to be infrastructure rather than code.

---

CIMD Replaces Dynamic Client Registration

One change stayed genuinely uncertain until the spec locked in. The release candidate signaled a move away from Dynamic Client Registration toward Client ID Metadata Documents, but the exact status of DCR wasn’t settled yet. The July 28 announcement has confirmed it. DCR is now formally deprecated in favor of CIMD. It keeps working for backward compatibility with authorization servers that haven’t added CIMD support yet, and it will be removed in a future spec version, not this one.

How Client ID Metadata Documents Work

CIMD changes where a client’s identity comes from:

• 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 who’s asking.

The practical effect is fewer moving parts during registration, and one less thing you have to defend against a spoofed client identity, since the metadata lives at a domain the client actually owns rather than in a registration response that can be replayed.

Why CIMD Improves MCP Authorization

CIMD ships alongside the wider set of authorization hardening changes in the same spec, including RFC 9207 issuer validation and the NSA and CISA guidance that pushed several of those SEPs forward in the first place. CIMD is the one piece of that picture that wasn’t confirmed when the release candidate came out.

---

What This Spec Means for Your MCP Setup

Nothing about July 28 forces an emergency migration on you. Where the real work lands depends on where you sit.

These checklists kept their shape between the release candidate and the shipped spec. Their status changed instead. They no longer depend on a draft locking in without surprises. Test against the shipped spec now, not the beta SDKs you were treating as a moving target through July.

---

Frequently Asked Questions

What is Model Context Protocol (MCP)?

Model Context Protocol (MCP) is an open standard that lets AI agents connect to external tools, data sources, and systems through one consistent interface, instead of building a custom integration for every tool. A client such as Claude or Cursor connects to MCP servers, and each server exposes tools the agent can call directly to search a database, read a file, or trigger an action outside the model itself.

How does MCP work?

MCP works through three participants, a host application like Claude Desktop, a client that maintains the connection, and a server that exposes tools, resources, and prompts. Messages pass between them as JSON-RPC calls. As of the 2026-07-28 specification, each request carries its own protocol version and identity information instead of relying on a session established earlier, so any server instance can answer any call.

Are Agent Skills replacing MCP?

No. Agent Skills and MCP solve different problems. MCP connects an agent to external tools, databases, and APIs it couldn’t otherwise reach. Skills package instructions and scripts that teach an agent how to approach a task, similar to an onboarding document for a new hire. Anthropic has said directly that it plans for Skills to complement MCP servers, not replace them, and most production agents end up using both.

What changed in the MCP 2026-07-28 specification?

The 2026-07-28 specification removed protocol-level sessions and the initialize handshake, replacing them with a stateless core where every request carries its own protocol version and identity. It also introduced Multi Round-Trip Requests, moved Tasks and MCP Apps into a formal Extensions framework, deprecated Dynamic Client Registration in favor of Client ID Metadata Documents, and started a twelve-month countdown on removing Roots, Sampling, and Logging.

What is the difference between Dynamic Client Registration and CIMD?

Dynamic Client Registration (DCR) has a client register itself with an authorization server at connection time and receive credentials back. Client ID Metadata Documents (CIMD) invert that. The client publishes its metadata at a URL it controls, and the authorization server fetches it to verify identity. The 2026-07-28 MCP spec deprecates DCR in favor of CIMD, though DCR still works for backward compatibility.

Can I use MCP and Agent Skills together in the same agent?

Yes, and most production setups already do. A Skill can tell an agent which MCP tool to call and in what order, while MCP handles the actual connection to the external system. A well-designed MCP server, including ones offered through a gateway like MCP360, can ship its own Skill alongside its tool definitions, so usage guidance travels with the server instead of living separately in every client.

Do I need to migrate my MCP server now that the spec has shipped?

It depends on how you run MCP. Teams hosting their own servers in production should audit session dependencies and deprecated features now, since the changes are no longer a release candidate. Teams reaching MCP tools through a gateway like MCP360 inherit most of the transport migration from their provider. Anyone using MCP only through a client such as Claude or Cursor sees no change at all.

How much can progressive discovery reduce MCP token usage?

Anthropic’s own testing found meaningful reductions. Loading MCP tools as code the agent can search instead of injecting every definition upfront cut token usage from 150,000 to 2,000 in one workflow, a 98.7 percent reduction. A separate Tool Search Tool test on a five-server, 58-tool setup cut roughly 55,000 tokens of overhead by 85 percent. Gateways like MCP360 apply the same search-first pattern by default.

---

Conclusion

The twelve-month deprecation window is the next date worth tracking, not July 28. Roots, Sampling, and Logging still work today, but the countdown on their removal has already started, and the SDKs shipping over the next year will nudge new projects away from them well before the formal removal date. Watch the SDK changelogs, not the spec page, to see it coming.

Skills becoming an open, cross-platform standard in December 2025 matters more than it looked at the time. Once clients beyond Claude read the same SKILL.md format, the “MCP vs Skills” framing gets harder to defend from either direction, since a Skill built once will run on several agents, and none of them stop needing MCP to reach outside the model.

The more interesting test isn’t the spec anymore. It’s whether progressive discovery, search first, load only what’s needed, becomes the default way agents work through large tool catalogs instead of a fix teams reach for after the first cost spike. Anthropic already ships it as a first-class pattern, not an afterthought, in Claude Code and the API’s Tool Search Tool. Whether MCP gateways and server authors build for it from day one, or bolt it on later the way most teams add caching, is the part still left to prove out.