From: aidotengineer
The Model Context Protocol (mCP) is envisioned as a foundational protocol for agents broadly, due to its specific protocol features and the increasing effectiveness of models in utilizing provided data [02:36:18]. This evolution allows agents to become more powerful and context-rich [06:28:30].
mCP’s Role in Augmented LLMs
mCP fits as the bottom layer of an augmented LLM system [02:49:54]. An augmented LLM takes inputs and produces outputs, using its intelligence to decide actions [02:37:31]. The “augmentation” comes from its ability to interact with retrieval systems, invoke tools, and manage memory [02:40:52].
mCP standardizes how AI applications interact with external systems [03:10] by facilitating communication with:
- Tools: Model-controlled functions for retrieving or sending data, updating databases, or interacting with local file systems [11:02:43].
- Resources: Application-controlled data exposed to the application, such as files (static or dynamic) or JSON data [11:23:0].
- Prompts: User-controlled, predefined templates for common interactions with a server [12:59:16].
This standardization allows agents to expand and discover different capabilities and interactions with the world even after initial programming or initialization [02:41:40]. Users can also customize how the agent interacts with their data [02:40:52].
“Agent systems at its core aren’t that complicated. They are this augmented LLM concept running in a loop where the augmented LLM goes and does a task, it kind of works towards some kind of goal, it invokes a tool, looks at the response and then does that again and again and again until it’s done with the task.” [02:54:33]
Key Protocol Capabilities for Agents
Sampling
Sampling is a feature where an mCP server can request LLM inference calls from the client [05:52:19]. This means the server does not need to implement or host its own LLM interaction [05:52:19]. The client retains full control over privacy, cost, and model preferences [05:42:0].
Composability
The logical separation between an mCP client and server means that any application, API, or agent can act as both [05:56:26]. This allows for chaining interactions and creating complex architectures with specialized layers of LLM systems [05:57:28]. For example, a main client can interact with an orchestrator agent (which is an mCP server), and that orchestrator agent can then act as an mCP client to invoke other specialized agents (e.g., analysis, coding, research) [06:05:0].
mCP Agent Frameworks
Frameworks like Last Mile AI’s mCP agent allow developers to define sub-agents (e.g., research agent, fact-checker agent, report writer agent) and give them access to various mCP servers (e.g., Brave for web search, Fetch for data pulling, file system for local access) [03:14:15]. This simplifies the development process as the agent builder can focus on the task and how the agent should interact with systems, rather than on the underlying servers or data [03:51:53].
Remote Servers and Authentication
Recent developments include support for remotely hosted mCP servers and OAuth 2.0 authentication [11:43:56]. This allows servers to live on a public URL and orchestrate authentication flows directly, with the server holding the OAuth token and giving the client a session token for future interactions [11:49:55]. This significantly reduces developer friction by making mCP servers as accessible as websites [11:50:5].
Registry and Discovery
A significant future development is an official mCP registry API [12:30:0]. This unified, hosted metadata service aims to solve discoverability issues for mCP servers [12:30:0]. It will provide a layer above existing package systems (like npm, pipie) to answer questions such as:
- What is the protocol (standard IO, SSE, local file, URL)? [12:29:0]
- Who built it, and is it trusted/verified? [12:29:0]
- What changes occurred between versions? [12:40:52]
This registry will enable agents to be “self-evolving” by dynamically discovering new capabilities and data on the fly, without needing pre-programming [13:59:0]. For example, a coding agent could search the registry for a verified Grafana server if it needs to check logs [13:59:0].
A complementary concept is a “.well-known/mcp.json” file for specific domains [13:52:0]. This would allow agents to discover mCP endpoints directly on a website, providing a verified way to use tools specific to that domain [14:07:0]. This approach can coexist with computer use models (e.g., LLMs that click around UIs), allowing agents to use direct APIs where available and UI interaction for long-tail cases [14:07:0].
Roadmap and Future Considerations
Medium-term considerations for mCP include:
- Stateful vs. Stateless Connections: Exploring short-lived HTTP-like connections for basic interactions versus long-lived SSE connections for advanced features like sampling and server-to-client notifications [14:11:32].
- Streaming: Supporting first-class streaming of data chunks from server to client within the protocol [14:39:41].
- Namespacing: Addressing tool name conflicts when multiple servers are installed, potentially through logical grouping of tools within the protocol [14:51:30].
- Proactive Server Behavior: Developing patterns for servers to initiate actions, such as event-driven notifications or requesting more information from the user [15:00:23].
Integration with existing systems
The speaker notes that mCP complements agent frameworks like LangGraph, rather than replacing them. Adapters can be built to connect existing agent systems to mCP servers, tools, and resources in a standardized way [01:17:18].