Anthropic Built MCP. Then It Shipped Skills. Is That a Pivot or a Plan?

MCP tells agents what is possible. Skills tell developers what’s ready. Those two clocks rarely tick together.

The thing MCP actually solved

When Anthropic introduced the Model Context Protocol (MCP) in late 2024, the pitch was clean:

stop doing N × M tool integrations,
standardise three primitives — tools, resources, prompts,
let any agent talk to any system over a predictable JSON-RPC-ish shape.

That was compelling enough that Figma exposed its design tree over MCP so agents could read structured layouts instead of pixels; LSEG exposed licensed market data that way so entitlements wouldn’t be bypassed even if an LLM was doing the calling. On paper, the protocol won — the world agreed on how to speak to systems.

That’s an interop win, not an adoption win.

MCP is the “USB-C” of this story: a uniform, boring, future-facing shape.

The thing MCP didn’t solve

Every serious MCP writeup in 2025 circled the same snag:

You still have to run an MCP server — a long-lived, reachable endpoint.
You still have to front it with identity / policy — no one wants agents to hit business systems anonymously.
You still have to make your IDE / agent discover it — registry, .well-known, or a manual config.
You still have to rate-limit and log it — because agents retry and fan out.

That is, MCP pushed complexity to the slowest-moving part of the org: the people who own networks, auth, audit. It was the correct architectural choice, but it meant MCP stopped one step before “use now.”

This is exactly the pattern we see in cloud outages and control-plane incidents: the hard part is not “can you run the compute,” it’s “can everyone find and coordinate the thing they need when the control layer blips.” Centralising capability makes sense — until a single control hop slows everything down.

Then came Skills — the fast path

In October 2025, Anthropic shipped Skills: bundles of instructions, scripts and resources that Claude can load only when a task needs them.

Key differences from raw MCP:

Zero infra: you don’t stand up a service; you publish a skill.
UI-first distribution: Claude on the web, Claude Code, agent SDKs can list and load skills.
Org-level curation: companies can maintain a catalog of “the way we do X here.”
Already running in Anthropic’s control plane: the “always-on” thing isn’t your problem anymore.

That reads like a contradiction: why evangelise MCP for a year and then ship a feature that dodges MCP’s hardest step?

It’s not a contradiction. It’s Anthropic acknowledging that discovery and packaging move faster than enterprise deployment. MCP is the long road; Skills is the on-ramp.

Or in one line: MCP won the spec; Skills won the moment.

So… pivot or plan?

The durable way to read this is: Anthropic is locking in a two-track agent ecosystem.

Track 1 — “Slow, heavy, correct”

who: Figma, LSEG, other vendors who must keep entitlements and audit
how: expose real systems over MCP, with identity, logging, policy
why: you want “bring the model to the data” without copying the data

Track 2 — “Fast, packaged, discoverable”

who: product teams, IDE users, agent builders
how: ship Skills that encode workflows, can optionally call MCP under the hood
why: you want “show me what I can do right now” without opening a port

If you look at it that way, Skills is not a pivot away from MCP; it’s a plan to make MCP actually show up in people’s workflows. The MCP server stays the source of truth; the Skill is the adapter people actually install.

Why this design has long shelf life

To make this piece age well, anchor it on constraints that don’t change fast:

Enterprise change-control is slower than agent iteration. Standards will always lag adoption. Skills give Anthropic a place to ship, test and iterate on workflows while MCP catches up with identity, async jobs and registry.
Control planes drift toward centralisation. Any agent ecosystem big enough will need a curated, signed, rated marketplace — otherwise companies won’t let agents roam. Skills is the natural place to enforce that; MCP alone isn’t.
Most developers won’t run servers for capabilities. 2025, 2026, 2027 — this won’t change. “Install a package” beats “operate a daemon.”

As long as these three hold, “MCP + Skills” looks like the stable shape, not a temporary scramble.

Strategic upside (and risk) for Anthropic

Upside:

Platform tax moves up: once Skills is the default packaging unit, the marketplace — not the protocol — becomes the place where monetisation, ranking and policy live.
Ecosystem gravity: IDEs and agent frameworks will integrate with Skills-level bundles because that’s what users see; they only need to support MCP to reach the heavy backends.
Spec still matters: MCP continues to be the neutral, open way to talk to systems, which keeps vendors comfortable.

Risk:

Skills becomes re-centralisation: if every “ready-to-use” capability must pass through Anthropic’s catalog, that’s classic platform lock-in wearing an agent hat.
MCP could look underused: if most day-to-day stuff is wrapped by Skills, raw MCP traffic may look thin — people might wrongly call the protocol a failure.
Competitors can copy the packaging: OpenAI, Google, Microsoft can all ship “skill-like” deployables that wrap whatever protocol wins; what Anthropic really has to defend is distribution, not just MCP.

What to watch next

Skills calling into enterprise MCP: the moment you can declare “this Skill talks to this MCP server behind this identity,” you get the best of both.
Third-party skill registries: if registries stay Anthropic-only, lock-in risk rises; if they federate, Skills turns into a genuine ecosystem.
Security vendors: once EDR / CSPM products start “seeing” Skills the way they now see serverless or GitHub Actions, you’ll know this model stuck.

The answer to the title

Is it a pivot or a plan?
It’s a plan — the plan to admit that protocols win arguments and packaging wins adoption.