The Evolution of MCP

What's next for the now popular Model Context Protocol (MCP)?

MCP is here to replace APIs. At least that's what many people in the API community believe in. To the point of evangelizing against using it. And, among the reasons those people present is the feeling that MCP was launched without being "production-ready." Well, I have to say that it was. The idea of building MCP actually started in 2024 and was solidified later in an internal hackathon at Anthropic. Since then, its creators have been following a lean approach and iterating on the original concept. Where exactly are they taking MCP next? Keep reading to learn more.

---

This article is brought to you with the help of our supporter, n8n.

n8n is the fastest way to plug AI into your own data. Build autonomous, multi-step agents, using any model, including self-hosted. Use over 400 integrations to build powerful AI-native workflows.

---

Not many people really know what MCP is and how it works. I was one of those people, I confess. Until not long ago, I only had a vague idea of what you can do with MCP, but I didn't have a deep knowledge of how it works. On top of that, reading people evangelize that MCP is bad and will kill APIs didn't help. That's why it would be a good idea to demystify MCP and show you the naked truth. In the words of David Soria, one of MCP's co-creators, the original problem to solve was the "copying and pasting between Claude Desktop and an IDE." MCP's original goal was then to bring information from the IDE directly into Claude Desktop, and to do so in a fully integrated way. That's why MCP servers didn't have any authentication or authorization initially. And, I guess that was the main point some people in the API industry complained about.

MCP means "Model Context Protocol." As the name implies, it's a protocol. What it means is that it establishes a set of rules that allows all the communication between an LLM and the outside world to become standardized. LLMs don't communicate directly with APIs. Instead, you need to provide tools that act as bridges between the LLM and any external APIs. That was until MCP was born. Since then, you don't have to worry about the LLM side of the communication any longer. You just have to implement the communication between the MCP and the external API.

The name MCP also reveals that its purpose is to provide context to the LLM. But what exactly is this context that we keep referring to? Context can be any information that is not available to the LLM that can help it make better decisions. It could, for example, be the files you have open on your IDE. Or, any actions that the LLM can take, APIs included. Or even ways to add information to the LLM context window through the use of prompts. Essentially, an MCP server can expose three main things: tools, resources, and prompts. Let's look at each one of these areas in detail because I feel most people only know about tools and neglect the other two topics.

Let's start with tools, then. These are executable actions that an MCP server exposes for invocation by clients or LLMs. Each tool is uniquely named and accompanied by a schema defining its input and output. A tool can, for instance, query a database, call an external API, manipulate a file, or perform a computation. Clients can list available tools via the tools/list method and request their execution via tools/call. While tools enable side‑effect‑driven behavior, implementations typically require user consent or confirmation before running any tool to ensure safety and human control.

A resource is a read‑only data entity that an MCP server can make available to clients. Resources are identified by URIs and may represent static files, database schemas, application metadata, or any other contextual information. Clients can list resources via resources/list and fetch them via resources/read. Resource templates support parameterized URIs, enabling dynamic data retrieval, e.g., users://{id}/profile. Resources help enrich the LLM context without causing side effects, making them ideal for supplying structured information for reasoning or generation.

Finally, prompts, in MCP, are reusable instruction templates exposed by servers to guide interactions with LLMs. Servers declare a prompts capability and make prompts available via prompts/list, allowing clients to retrieve and instantiate them with arguments. A prompt template structures messages, such as "summarize this document" or "generate a query," and can embed parameters. Clients choose prompts explicitly, and then pass arguments to generate tailored instructions for the model. Prompts streamline workflows and help ensure consistent, optimized interactions for specific domains or tasks.

So, users have to explicitly choose which prompt they want to use. But how do LLMs decide which tool to use or which resource to load? Tool usage is decided based on how well a prompt semantically matches the tool description. Each tool has a name, a description, and a definition of its input and output schemas. Whenever a user submits a prompt to the LLM, it goes through all the available tools and tries to find the one that best fits the user's intent. The case of resources is similar. However, since resources provide URI templates, the LLM also attempts to extract information from the prompt to fill in the template. So, for example, whenever a user types something like "Show me the profile of user 42," the LLM will use the users://{id}/profile and fill in 42 as the user's ID. Clever, right?

Even with just these three features, the possibilities are limitless. Now, imagine adding more capabilities to MCP. The first big improvement, according to Theo Chu, a Product Manager at Anthropic, is investing in better documentation. Even though the existing website provides good guidance, there's still room for improving the information being shared with first-time developers. The second area that deserves more attention is definitely security-related primitives. This area generated a lot of complaints from API industry experts and needs to be fixed quickly. The third area is related to the ability that agents have to find MCP servers. They call this capability the registry API, and it will allow LLMs to dynamically look for MCP servers when they're not "happy" with the ones they already know about. Finally, another area that will add more capabilities is called elicitation. It's the ability to ask the user for input during a task. Now, some of these capabilities are already being implemented, some others have been partially implemented, and others are still being planned. Remember that MCP is an open source project that anyone can access, review, and participate in.

There are many available resources for those interested in learning more about MCP. I wrote about it a few times before. You can start by reading Model Context Protocol vs. Programmatic Workflows where I compare the traditional workflows with what you can do with an MCP. Then, I recommend API Translation Layers, which covers the role of JSON-RPC, the API style that MCP uses. Follow it with Intent-based API Discovery and What Language Do AI Agents Speak? to learn about intent-based UIs. And, finally, I recommend Agentic Workflow Authorization if you're interested in OAuth and dynamic client registration. MCP is definitely an area that is expanding and that I'm paying attention to. It's the glue between LLMs and APIs and, as such, is not something to neglect.

---