By now you’ve probably heard about the Model Context Protocol (MCP). My last post talked about it a bit, but in the particular context of identity issues.
The technology is incredibly promising. It aims to provide a standard mechanism to let generative AI systems discover and use external resources. However, like everything in genAI land, its application is evolving rapidly. This is especially true with the rise of distributed agentic systems, and it’s in this space that what I think is a fairly large gap in the protocol itself becomes quite apparent. Let’s take a look.
Current MCP Paradigm 💻
Currently, the MCP host handles a wide range of responsibilities:
- User interactions and permissions 🔐
- Initiating connections to the MCP server via clients 🔗
- Orchestrating the flow between user requests, LLM processing, and external tools ⚙️
- Rendering results back to users 🎨
This model works well for desktop user interfaces (like Claude Desktop, Cursor, etc.), where the host is tightly coupled with the UI.
The Shift to Agentic Systems 🌐
However, the landscape is changing. We’re moving towards more distributed agentic systems, where the current paradigm doesn’t always fit. Here’s why:
- Remote Servers: Many current MCP servers are stdio-based and run on localhost. This is fine for specific tasks, but distributed platforms will primarily use remote servers. ☁️
- Decoupled Components: The MCP “host” is often the user interface, but this is changing. Even in desktop apps, reasoning engines are being separated from UI components like chat interfaces. In distributed systems, this is even more common, with components handling planning and coordination. 🧩
Challenges with the Current Paradigm 🤔
This shift creates some challenges:
- The current documentation and examples are geared towards a use case that is rapidly evolving. 🚀
- The current use case may not fully represent the intended purpose of the protocol. 🎯
- The protocol supports more scenarios than are currently being highlighted. 💯
Rethinking MCP Host Responsibilities 🧠
As we already covered, functionalities outside the reasoning process and client handling (such as authentication, rendering results, etc.) are currently handled by the MCP “host”, and this definiton works great when everything is all together.
In distributed agentic systems though, when these components are separate components, it’s unclear within the spec where these functionalities should occur. This causes problems for developers of agentic AI applications and systems, as well as the security teams providing guidance to them.
Proposed Evolution of MCP 🚀
It seems logical that the reasoning and client handling elements need to be broken out from the other functions the host is performing. Here’s a potential evolution:
- MCP Host: Focus on reasoning and managing clients. This includes receiving output from clients and iterating on results until the task is accomplished. 🎯
- Other Components: Authentication, authorization, user interaction, and result rendering would be handled by other components in the stack.
Introducing the “User” Layer? 🧑🧑🧒🧒
One potential location for these functionalities is a new “user” layer. The user (or at least, the interface with the user) is a component that appears to be missing entirely from the protocol in its current state, having been bundled in with “host”. 😮
If integrated into the protocol, the new user layer could handle:
- Authentication and authorization.
- User interaction.
- Result presentation.
This leaves the host layer free to do what its primary role is: managing clients, iterating through output, and monitoring tasks until they are completed.
By introducing a dedicated user layer, the MCP can become more flexible and adaptable to the needs of distributed agentic systems. For the current state of desktop apps, things don’t need to change; the user layer and the host can just stay integrated together as they currently are.
This may provide a best path forward for the protocol, allowing it to expand as needed to the different use cases AI systems support while needing no changes for existing scenarios.