Note: This is going to be acronym-heavy article 😅 It might even sound like rap rhymes if you read it fast enough.
MCP is all the rage right now, and rightfully so if you ask me. As agents step into the spotlight as a promising pathway for deeply embedding AI into our lives (at companies and homes) MCP promises to be the plumbing that makes these systems interoperable and useful.
Some have compared MCP’s potential impact to that of TCP/IP during the early days of the internet: not the flashy part, but a foundational layer that enabled the web’s explosion in scale and innovation. Connected computers were coming no matter what, but TCP/IP accelerated the timeline. Could MCP do the same for agent-based systems?
It works… but it’s… raw?
Once you start playing around with MCP, you quickly see that while it works, it feels… somehow raw. Maybe even intentionally so. It’s low-level enough to be powerful and flexible, but that comes at the cost of developer convenience and standardization.
Which raises the question: if MCP is the TCP/IP, where’s the HTTP?
Is an upper layer necessary?
The amazing power of LLMs and its development makes you occasionally question myself which prior experience or assumptions we should drop when understanding these challenges. This is one such case, in which it seems like MCP might actually benefit from its current structure based around Resources, Actions, and Prompts.
Yet, it seems like as integrations deepen more structure could be necessary to support more advanced use cases as use cases evolve. While a Resource might have a right balance of abstraction and implementation at this point, as common patterns emerge in integrations with different families of tools the point can be made that it will need a way to address more effectively.
Something that can codify best practices, enforce common patterns, and reduce the friction of building and maintaining multi-agent systems.
What about Prompts?
MCP already includes a concept of Prompts, which can act as templates or structured messages for invoking agent actions in predictable ways. These could certainly have a role in providing more sophisticated and predictable behavior for each server, but it remains to be seen if we would arrive at a scenario where sets of prompts could be reused and standardized for across families of use cases/services.
Think like a standard set of MCP Prompts for use cases (e.g. email, project management, image catalogue) that a server could comply with for easier integrations with suitable LLMs.
Isn’t MCP more like <another protocol acronym>?
You might argue that MCP is more akin to something like gRPC, AMQP, or even REST! And you’re probably not wrong. I’m not claiming a 1:1 match with TCP/IP, HTTP, or anything else. My point is more conceptual: MCP might be a foundational enabler, but if we want broad and meaningful adoption, I can imagine a strong need ahead for a next layer of abstraction.
Juan Saavedra 