Tubegraph

Model Context Protocol mCP Overview

7 min read

From: aidotengineer

The Model Context Protocol (mCP) is an open protocol designed to enable seamless integration between AI applications, agents, and external tools and data sources [01:55:00]. Developed by Anthropic, its core philosophy stems from the understanding that models are only as effective as the context provided to them [01:18:00].

Motivation and Background

Historically, providing context to AI chatbots or applications involved manual methods like copy-pasting or typing [01:33:00]. Over time, these systems evolved to include “hooks” into user data and context, making them more powerful and personalized [01:46:00].

mCP’s development was inspired by prior standardization efforts in software development:

  • APIs (Application Programming Interfaces): Standardized how web applications interact between front-end and back-end, allowing front-ends access to servers, databases, and services [02:12:00].
  • LSP (Language Server Protocol): Standardized how IDEs interact with language-specific tools, enabling an LSP-compatible IDE to understand and interact with different coding language features [02:40:00].

Before mCP, the industry faced significant fragmentation in building AI systems [03:41:00]. Different teams or companies would create custom implementations for integrating AI apps with context, often involving unique prompt logic and varied methods for bringing in tools and data [03:53:00]. mCP aims to standardize this process, acting as a layer between application developers and tool/API developers to provide Large Language Models (LLMs) with access to data [06:06:00].

Key Components of mCP

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

  1. Tools: These are “model-controlled” [10:27:00]. The mCP server exposes tools to the client application, and the LLM within the client decides when to invoke them based on descriptions provided by the server [10:32:00]. Tools can perform actions like retrieving data, sending data to applications, updating databases, or writing files [11:04:00].
  2. Resources: These are “application-controlled” data exposed to the application [11:23:00]. The server can define or create resources like images, text files, or JSON data, which the application then decides how to use [11:31:00]. Resources provide a richer interface for applications and servers to interact beyond simple text chats [11:50:00]. Resources and prompts can be dynamic, interpolated with context from the user or application [20:58:00]. Clients can also subscribe to resource notifications, where the server notifies the client when a resource is updated [21:17:00].
  3. Prompts: These are “user-controlled” [12:59:00]. Prompts are predefined templates for common interactions with a specific server [13:08:00]. Examples include slash commands in an IDE to summarize work or standardized document Q&A templates [13:14:00].

The distinction between tools, resources, and prompts emphasizes that mCP isn’t solely about improving the model, but also about defining how the application interacts with the server in richer ways [14:44:00]. It provides more control to different parts of the system: model, application, and user [22:26:00].

Value Proposition and Adoption

mCP offers benefits across the AI ecosystem:

  • Application Developers: Once an mCP client is compatible, it can connect to any server with zero additional work [05:42:00].
  • Tool/API Providers: They can build their mCP server once and see it adopted across various AI applications [05:51:00].
  • End-Users: Experience more powerful and context-rich AI applications that can understand and act on their behalf [06:28:00].
  • Enterprises: mCP provides a clear way to separate concerns between teams [06:48:00]. For instance, one team can own and maintain an mCP server for a vector database, allowing other teams to build AI apps faster without needing to understand the underlying infrastructure [07:21:00]. This fosters a microservices-like environment for AI development [07:49:00].

mCP has seen rapid adoption since its launch [08:05:00]. It’s used in applications and IDEs like Cursor and Windsurf, and agents like Goose [04:26:00]. Over 1100 community-built servers have been published open source, alongside servers built by companies offering official integrations [08:47:00]. This includes significant open-source contributions to the core protocol [09:07:00].

Example Use Case: Claude for Desktop

In Claude for Desktop, an mCP client, a user can provide a GitHub repo URL and ask Claude to triage issues [23:01:00]. Claude automatically invokes the list issues tool, pulls in context, and summarizes the issues based on user preferences [23:29:00]. Claude can then use other installed mCP servers, such as an Asana server, to list workspaces, search projects, and add tasks [24:19:00]. Crucially, these Asana and GitHub servers can be built by the community (often in just a few hundred lines of code) and seamlessly interoperate with Claude for Desktop [24:52:00].

mCP’s Role in Agentic Systems

mCP is envisioned as a foundational protocol for agents [26:36:00]. It aligns with the concept of an “augmented LLM,” where an LLM is enhanced with retrieval systems, tools, and memory to query/write data and invoke actions [27:29:00]. mCP serves as the underlying layer that federates and simplifies how LLMs interact with these components in a standardized way [28:10:00]. This means agents can expand their capabilities dynamically, even after initialization, by discovering new interactions with the world [28:34:00].

Two key protocol capabilities contribute to mCP’s role in agents:

  1. Sampling: Allows an mCP server to request LLM inference calls (completions) from the client [53:52:00]. This federates requests, letting the client own the LLM interactions (hosting, model choice, privacy, cost) while the server can request intelligence using various parameters (model preferences, prompts, temperature, max tokens) [54:52:00].
  2. Composability: mCP’s design allows any application, API, or agent to be both an mCP client and an mCP server [56:21:00]. This enables chaining of interactions, where a user talks to a client, which calls an agent (acting as a server and client), which in turn calls other specialized servers (e.g., file system, web search) [56:40:00]. This allows for complex, hierarchical architectures where each layer specializes in a particular task [57:28:00].

The combination of sampling and composability is particularly exciting for agents, enabling hierarchical systems where agents can federate sampling requests through layers to the core application controlling the LLM [01:11:41].

Roadmap and Future Directions

The development and adoption of MCP continues with several key initiatives:

Remote Servers and Authentication

mCP now supports remotely hosted servers via Server-Sent Events (SSE) and includes OAuth 2.0 support for authentication [01:13:59]. This means servers can live on public URLs and orchestrate the authentication handshake with external services (e.g., Slack), holding the OAuth token and providing the client with a session token for future interactions [01:14:19]. This significantly reduces developer friction by removing the need for users to manually interact with local environments or understand mCP hosting [01:15:40].

mCP Registry

A major challenge has been the lack of a centralized way to discover and integrate mCP servers [01:22:00]. An official mCP registry API is under development. This will be a unified, hosted metadata service, built in the open, that will address issues like:

  • Discoverability: Making it easy for users to find mCP servers [01:23:50].
  • Protocol Details: Identifying whether a server uses standard I/O, SSE, is local, or lives at a URL [01:23:09].
  • Trust and Verification: Indicating who built a server and if it’s officially verified (e.g., by Shopify) [01:23:25].
  • Versioning: Providing a log of changes to servers, including tool additions or description modifications [01:24:01].

The registry will enable agents to be “self-evolving” by dynamically discovering new capabilities and data on the fly, without needing to be pre-programmed with all possible tools [01:36:01].

.well-known Endpoints

Complementing the registry is the concept of .well-known mCP.json endpoints [01:39:27]. Similar to how websites use .well-known directories, this allows entities like shopify.com to host a standardized file (.well-known/mcp.json) describing their mCP endpoint, capabilities, and authentication methods [01:39:30]. This provides a “top-down” approach for agents to verify and connect to known services, combining with a “computer use” model (where an LLM can click around UIs without APIs) for comprehensive interaction [01:40:07].

Medium-Term Considerations

  • Stateful vs. Stateless Connections: Exploring short-lived connections for basic requests (e.g., HTTP) alongside long-lived connections (e.g., SSE) for advanced capabilities like sampling and server-to-client notifications [01:41:41].
  • Streaming: How to support streaming multiple chunks of data from server to client first-class in the protocol [01:42:41].
  • Namespacing: Addressing conflicts when multiple servers expose tools with the same name, potentially through logical groups of tools [01:42:51].
  • Proactive Server Behavior: Developing patterns for servers to initiate actions, such as asking for more user information or sending event-driven notifications, without being explicitly prompted by the client [01:43:31].

While mCP aims to be a standard layer for context, it does not replace agent frameworks, but rather complements them by simplifying how agents hook into servers, tools, prompts, and resources [01:17:12]. It empowers agent builders to focus on the core agent loop, knowledge management, and orchestration [01:18:41].

Graph View