Is the Age of MCP Over? Tool Integration Design in the Age of Skills Compilation¶

Target Audience

Engineers seeking to understand the differences between MCP and Skills
Practitioners looking to improve token efficiency in agent design, Develope...

Key Points¶

What the claim "MCP is obsolete" actually refers to
The concept of Skills (SKILL.md-based) and how it differs from MCP
Where context consumption occurs and how to break it down
Decision criteria for choosing between MCP and Skills

The Bottom Line: It's the Usage Pattern, Not the Protocol¶

Let's be clear from the start.

MCP as a protocol is not outdated. What's being criticized is the usage pattern of "exposing MCP servers as massive API dictionaries and having LLMs explore them while performing repeated low-level operations."

The real question isn't "whether to use MCP" but "how to use it."

Terminology¶

Before diving in, let's clarify the terms used in this article.

Term	Meaning
MCP (Model Context Protocol)	A standard interface for LLMs to call external tools
Context	The scope of information an LLM can process at once (conversation history + instructions + data)
Tokens	Units of text processed by LLMs. In English, roughly 1 token per 4 characters
Skills	A mechanism for packaging work procedures and passing them to agents (proposed by Anthropic)

MCP Basics: How LLMs Call External Tools¶

MCP is a protocol that standardizes the "conventions" for LLMs to call external tools.

A client (IDE or chat UI) connects to an MCP server
The LLM calls tools (functions) provided by the server
Results are returned to the LLM and reflected in the conversation

This is straightforward. The problem lies in what comes next.

Want to Understand the Full Picture of MCP?

For a comprehensive overview of MCP's structure and use cases, see the "MCP Complete Understanding Dashboard."

What "Context Melting with MCP" Actually Means¶

The phrase "context melting" is commonly used, but there are two types of token consumption. This distinction matters.

Exploration Tokens (Tool Selection & Procedure Discovery)¶

Tokens consumed as the LLM figures out "which tool to use" and "what arguments to pass."

Which API should I use?
What's the argument format?
That failed—what's an alternative approach?

This "figuring out how to do it" conversation accumulates and pressures the context window.

Actual Data Tokens (Volume of Data Being Processed)¶

Tokens consumed by the actual retrieved data (Slack logs, document contents, etc.).

This occurs with both MCP and Skills whenever the data volume is large.

Key Point

When people say "MCP is heavy," the primary issue is exploration tokens.

Slack Integration Example: What Tends to Happen with MCP¶

Consider a concrete example: "Collect specific Slack threads and create meeting minutes."

When an MCP server exposes many low-level Slack APIs, the LLM tends to go through explorations like these:

Finding how to identify threads (search? history? URL?)
Narrowing down candidates
Extracting message content via the retrieval API
Hitting rate limits or permission errors → exploring alternative routes
Formatting the retrieved logs into meeting minutes

This "exploration + trial and error" drives up exploration tokens.

What Are Skills: Packaging Work Units¶

Skills is an approach where work procedures are pre-packaged and handed to the agent.

The components are:

SKILL.md: A file describing procedures, rules, and input specifications
Scripts: Code that automates routine processes
Related resources: Templates and configuration files

The key point of Skills is narrowing the "exploration space" visible to the LLM.

Instead of showing the entire Slack API, you hand over only the entry point for the "create meeting minutes" task. This reduces exploration tokens.

Skills Resources

Skills Are Not a Silver Bullet¶

That said, introducing Skills doesn't eliminate exploration entirely.

The LLM still reads the SKILL.md and makes decisions. If the SKILL.md is ambiguous or unexpected input arrives, exploration will occur.

Skills are most effective when these conditions are met:

The work can be standardized
Input specifications are clear
Exception handling is limited

Note that Anthropic's official guidelines recommend keeping SKILL.md content under 500 lines. Skills have their own context management constraints.

MCP and Skills Can Be Used Together¶

While we've presented them contrastively so far, MCP and Skills aren't an either/or choice.

According to Anthropic's official position, MCP connects LLMs to external services while Skills teach effective tool usage—both are designed to be used in combination.

For example, you can establish a connection through Notion's MCP server while using Notion-specific Skills to teach the LLM how to handle the data.

When MCP Becomes the Better Choice¶

So when is MCP most effective? In cases where factors other than tokens become dominant.

When You Need Centralized Governance¶

Audit logs, permission management, and rate limiting can all be managed centrally on the server side. MCP's architecture emphasizes security and controlled access, allowing organizations to strictly manage what AI assistants connect to.

IDE agents, chat UIs, batch processes, and other teams' bots can all use the same connection and permission model.

When Exploration Itself Has Value¶

For cases like "the question is different every time" or "cross-cutting search is the goal," fixing things into Skills actually loses flexibility.

During PoC Phases with High Volatility¶

Building out Skills when requirements aren't solidified leads to significant rework.

Centralizing on MCP Has Trade-offs¶

Consolidating integrations into an MCP server creates a single point of control, but carries these risks:

A server failure affects all agents
API updates propagate to all clients
The server administrator becomes a bottleneck

On the other hand, distributing via Skills also has challenges: scattered and duplicated skills, difficulty auditing, and knowledge silos.

This is a centralization vs. distribution trade-off—neither is inherently correct.

Implementation Pattern Details

For concrete MCP server implementation patterns, see "MCP Server Implementation Patterns."

Decision Criteria: A Checklist¶

Cases Where Skills Takes Priority¶

Running the same type of work weekly or more frequently
Stable specifications
High failure cost requiring reproducibility
Can be completed locally or in CI

Cases Where MCP Takes Priority¶

The question differs each time (exploration has value)
Sharing across multiple teams and clients
Centralized governance of auditing, permissions, and secrets
PoC phase with fluid requirements

Summary¶

The claim "MCP is obsolete" is not a criticism of the protocol itself—it's a criticism of a specific usage pattern.

MCP excels at "connecting, sharing, and governing"
Skills excels at "standardizing repetition and reducing exploration"
Both can be used together, combined according to purpose

The choice between them should factor in not just token efficiency, but also governance, sharing, and resilience to change.

Appendix: Code Execution with MCP¶

While not covered in this article, Anthropic proposed a new pattern combining MCP with code execution in 2025.

In this approach, the agent treats MCP servers as code APIs, loads tools on demand, processes data within an execution environment, and returns results to the model. Official benchmarks reported reducing 150,000 tokens to 2,000 tokens (a 98.7% reduction) in certain cases.

This approach is effective for complex workflows involving many MCP servers (10+) and cases processing large volumes of intermediate data.

For details, see Anthropic's engineering blog post "Code Execution with MCP."