From: aidotengineer

Model Context Protocol (mCP) is an open protocol designed to enable seamless integration between AI applications and agents with external tools and data sources [02:00:00]. Developed by Anthropic, mCP is rooted in the philosophy that models are only as effective as the context they are provided [01:18:00].

Motivation and Precursors

Historically, providing context to AI assistants or chatbots involved manual copy-pasting or typing [01:33:00]. Over time, systems evolved to allow models direct hooks into user data and context, making them more powerful and capable of personalized interactions [01:46:00]. mCP was launched to standardize this interaction [03:10:00].

The development of mCP drew inspiration from preceding protocols:

  • APIs (Application Programming Interfaces): Standardized how web applications interact between front-end and back-end, translating requests and allowing access to servers, databases, and services [02:15:00].
  • LSP (Language Server Protocol): Standardizes how Integrated Development Environments (IDEs) interact with language-specific tools [02:40:00]. An LSP-compatible IDE can interact with features of different coding languages by hooking into a single LSP server [02:50:00].

Before mCP, the industry faced significant fragmentation in building AI systems, with different teams creating custom implementations for prompt logic, tool integration, and data access [03:41:00]. mCP aims to standardize AI development, providing a common interface for AI clients to connect with any mCP server [04:18:00].

Core Components of mCP

mCP standardizes how AI applications interact with external systems through three primary interfaces [03:14:00]:

  1. Tools: These are “model-controlled” capabilities [10:27:00]. mCP servers expose tools, and the Large Language Model (LLM) within the client application chooses when to invoke them [10:37:00]. This allows LLMs to retrieve data (read tools), send data to applications (write tools), update databases, write files, and perform actions in various systems [11:05:05].
  2. Resources: These represent “application-controlled” data exposed to the AI application [11:27:00]. Servers can define and create static or dynamic resources (e.g., images, text files, JSON) [11:31:00]. The application then decides how to use these resources [11:45:00]. Resources provide a richer interface for interaction beyond simple text-based chatbots [11:50:00].
  3. Prompts: These are “user-controlled” predefined templates for common interactions with a specific server [12:59:00]. Users can invoke these prompts, which are then interpolated with context and sent to the LLM [13:35:00].

Separation of Control

A key design principle of mCP is the clean separation between what is model-controlled (Tools), application-controlled (Resources), and user-controlled (Prompts) [15:00:00]. This allows for richer interactions where the application can decide when to use a resource based on predefined rules or LLM calls, rather than relying solely on the model [15:06:00].

Value and Adoption

mCP provides value across the ecosystem:

  • Application Developers: Can connect mCP-compatible clients to any server with zero additional work [05:42:00].
  • Tool/API Providers: Can build an mCP server once and see it adopted across various AI applications [05:51:00]. This addresses the “N times M problem” of many permutations for client-server interaction [06:06:00].
  • End Users: Benefit from more powerful and context-rich AI applications [06:28:00] that can take action in the real world [06:45:00].
  • Enterprises: Gain a clear way to separate concerns between teams. One team can own and maintain an mCP server for shared infrastructure (e.g., a vector database), allowing other teams to build AI applications faster without needing to rebuild access methods [06:48:00].

Adoption has been significant, with mCP appearing in almost every Anthropic conversation [08:08:00]. Examples of mCP clients include Anthropic’s first-party applications, Cursor, Windsurf, and agents like Goose by Block [04:26:00]. Over 1,100 community-built servers have been published open source [08:47:00], alongside servers built by companies and official integrations [08:54:00].

mCP’s Role in Augmented LLM Systems

mCP is envisioned as a foundational protocol for agents [02:36:00]. An augmented LLM is an LLM that can interact with external systems like retrieval systems, tools, and memory [02:41:00]. These augmentations allow the LLM to query and write data, invoke tools, respond to results, and maintain state [02:49:00].

mCP as the Augmentation Layer

mCP fits in as the “entire bottom layer” of an augmented LLM system [02:14:00]. It federates and makes it easier for LLMs to communicate with retrieval systems, invoke tools, and access memory in a standardized, open way [02:17:00].

This standardization means:

  • Dynamic Capability Expansion: Agents can expand their capabilities even after initialization, discovering new interactions with the world without being pre-programmed [02:34:00].
  • Focus for Agent Builders: Agent builders can concentrate on the core agent loop, context management, and how the LLM uses memory, rather than on building custom integrations with every tool or data source [02:47:00]. Users can also customize the agent by bringing in their own context and data sources [02:40:00].

Key Protocol Capabilities for Agents

  1. Sampling: Allows an mCP server to request LLM inference calls (completions) from the client, rather than implementing LLM interaction itself [02:54:00]. This allows the client to own LLM hosting, model choices, privacy controls, and cost parameters, while the server requests intelligence [02:58:00]. This is crucial for servers that need intelligence but don’t know anything about the client initially [02:59:00].
  2. Composability: A logical separation where any application, API, or agent can simultaneously be both an mCP client and an mCP server [02:26:00]. This enables chaining of interactions, where a user talks to a client (e.g., Claude for Desktop), which acts as a server to an agent, which in turn acts as a client to other mCP servers (e.g., file system, web search) [02:40:00]. This allows for complex, multi-layered LLM architectures where each layer specializes in a particular task [02:57:00].

Road Map and Future of mCP

The future of mCP involves several key developments:

  • Remote Servers and Authentication: mCP now supports remotely hosted servers over Server-Sent Events (SSE) [15:09:00] and integrates with OAuth 2.0 for authentication [15:34:00]. This reduces developer friction, allowing users to connect to servers without needing to understand hosting or building [15:40:00]. The server manages the OAuth handshake and holds the token, federating interactions between the user and the end application [15:42:00].
  • mCP Registry API: Addressing the lack of a centralized way to discover and pull mCP servers [16:02:00]. This unified, hosted metadata service will make it easier to discover servers, verify their source (e.g., official Shopify server), and manage versioning [16:32:00]. The registry will facilitate agents becoming “self-evolving” by dynamically discovering new capabilities and data on the fly [16:04:00].
  • Well-Known mCP JSON: A complement to the registry, allowing organizations to publish a standard JSON file (e.g., /.well-known/mcp.json) describing their mCP endpoint, resources, and tools [16:27:00]. This provides a verified, top-down approach for agents to discover and interact with specific services [16:17:00]. It also complements “computer use” models, allowing agents to combine API calls with UI interaction for the long tail of functionalities without dedicated APIs [16:45:00].

Medium-Term Considerations

  • Stateful vs. Stateless Connections: Exploring more short-lived connections, allowing clients to disconnect and reconnect while continuing conversations without re-providing data [17:41:00].
  • Streaming: Enhancing the protocol to support first-class streaming of multiple data chunks from server to client over time [17:41:00].
  • Namespacing: Addressing conflicts when multiple servers have tools of the same name, potentially through logical grouping of tools within the protocol [17:54:00].
  • Proactive Server Behavior: Developing patterns for event-driven servers to initiate actions, such as asking the user for more information or notifying them about updates [18:33:00].