MCP is Dead! Long Live MCP
A closer look at MCP x Skills, and why you will probably use both
Technology moves so fast in the age of AI that newly introduced standards or tools can be relegated to obscurity from their glorious days sooner than ever.
The latest victim seems to be model control protocol (MCP), which was introduced by the end of 2024 by Anthropic before being turned into an open standard and adopted by all LLM/AI tool providers.
All of a sudden, its popularity grew with thousands of MCP servers available. All seemed fine until the introduction of Skills, yet again, by Anthropic.
The buzz is that the era of MCP seems to be over, but before making this decision, I believe we should take a step back, understand what each one can offer, their limitations, and their strengths.
Spoiler alert: No, I do not believe Skills really eradicates the usability of MCPs, but there is a clear overlap and reasons why one may be more suited than the other.
Knowledge Limitation
LLMs are trained with vast amounts of data from many public sources, including the content found on the web.
At one point, they stop feeding new information, and the model is made available. This means that each new model has a different knowledge cutoff date, with newer models usually sporting more recent cutoff dates than their predecessors.
Because they are only provided with public information, any content on the deep web is not included in their training data. That includes password-protected pages, private databases, subscription-based content, and all sorts of corporate or government intranets.
If you add both together, a gap is formed that can limit the ability of any LLM-backed agent/solution to help you.
Unless there is a way to expose the information to the LLM...
Before MCP
Our solution to the limitation is to expose the AI application to external sources/systems. Before MCP, the available solutions were:
Retrieval-Augmented Generation
At query time, relevant documents are retrieved from a knowledge (vector) database and added to the prompt as context.
Fine-Tuning
You take an existing model and essentially train it with the information it is missing.
Custom Tool/Function Calling
Each model provider, such as OpenAI and Anthropic, enabled developers to define their tools. The LLM used this definition to choose which tool to use and informed the application, which executed the call and returned the response to the LLM.
Given that tool calling was the most common case, let’s explore it further.
For example, you want to give access to your product database. The tool definition could look like this
Then you make the request using your prompt and the list of tools
The LLM would return which tools to call, and you do the routing
As you can imagine, this was a considerable effort on the application side, and the fact that there was no standard meant that using different models was an additional challenge.
Enter MCP…
MCP
MCP comes with a standard way for applications to connect to external sources, such as databases, files, call tools, and express “workflows”.
The immediate benefits ranged from the usual ones from standards (a unified way to define your tools, to handle requests/responses, authentication…), to the flexibility of being LLM agnostic and creating an ecosystem, like the GitHub MCP registry.
Main Concepts
There are three participants:
MCP Host - the AI application (Claude Code, Visual Studio Code, Your application) that coordinates the MCP Clients
MCP Client - the component that establishes/maintains the connection to the MCP server for the host to use
MCP Server - the component (local or remote) that provides the context to the clients. In the case of a local MCP server, the code it contains is executed locally and performs the actions you requested.
MCP standard defines 3 primitives that servers can define and are used by clients:
Tools - a list of functions that AI applications can invoke
Tools offer two operations: list (to discover the available tools) and call (to invoke a specific tool).
Resources - data sources that provide additional information to the model
It can be direct resources, such as URIs that point to a specific resource. events://apointments/123, or templates that accept dynamic parameters, trips://itinerary/{itineraryId}.
Resources offer four operations: list (to discover available direct resources), templates/list (for template resources), read (to retrieve the contents of a resource), and subscribe (to monitor changes to a specific resource).
Prompts - reusable templates that the AI application can use with the LLM. A common usage is to provide a workflow/recipe definition so the LLM knows what to ask the user/other MCP tools.
Prompts offer two operations: list (to discover available prompts), get (to retrieve the prompt details)
MCP defines 3 primitives that a Client can offer
Elicitation: A server can request specific information from the client to perform the functionality.
This is passed to the MCP host and to the end user.
The user can accept, decline, or cancel this request.
So, imagine the booking of the medical appointment. For a given speciality, additional information is required. The server could send an elicitation request back to the client asking for that.
There are two modes of elicitation, form (seen in the previous example), where the MCP Host would ask for the information, and the answer is passed back to the server, as seen below
The other is the URL mode, where the user would interact with another system outside the server for perhaps sensitive or regulated flows.
In this case, we need the user to authorize the responsible entity to access their medical records.
And then the server can notify of the closure of the elicitation flow.
Roots - indicate boundaries for the server to operate within the host’s filesystem
You can think of it as the reverse of the server Resources definition. In the server case, Resources define what the client can access from the server. For the roots, they specify the data that the server can touch on your machine.
Roots offer a single operation: list (to provide the list of roots)
Sampling - enable servers to request, via the client, language model completions.
The server sends a prompt to the client, which is in control of the security, presents the request to be approved, and if so, passed to the LLM. The response follows a similar path, but only being sent back to the server is approved.
This would fit in the case where a tool call returns some information, but the interaction expects additional reasoning to take place, and the server offloads/delegates this back to the client.
The server can suggest a model, reasoning parameters, and provide user and system prompts.
Notifications
The protocol supports real-time notifications as a way to provide updates between both parties. If something changes, such as new tools, the server can send update notifications to connected clients.
We already saw a notification in the elicitation case where the client informed the server that a specific elicitation request was completed.
You can find this behavior for many primitives, client or server ones.
Server
Tools - notifications/tools/list_changed
Prompts - notifications/prompts/list_changed
Resources - notifications/resources/list_changed
Client
Roots - notifications/roots/list_changed
The flow is the same for all, during initialization client (or server) informs that for a given feature, they support the capability of notifying when changes happen (listChanged: true).
Then, if there is a change, the client (or server) will notify the other party of this. It will then be their responsibility to request the updated list of the feature.
Skills
Similar to MCP, Skills come as a way to offer additional context to agents but do so in a different, more lightweight fashion.
A skill consists of a file SKILL.md and optional additional components (scripts, references, assets)
SKILL.md - contains metadata (YAML frontmatter) and the instructions that your skill wants the agent to follow
Scripts - executable code to be invoked as part of the instructions
References - documentation that the agent can use, if needed
Assets - templates and additional resources that the instructions may indicate for usage
