Integration and adoption of mCP in AI applications

From: aidotengineer

The Model Context Protocol (mCP) is an open protocol developed by Anthropic’s applied AI team to enable seamless integration between AI applications and agents with various tools and data sources [01:58:00]. It addresses the core concept that models are only as effective as the context provided to them [01:19:00].

Motivation Behind mCP

Historically, AI applications and chatbots required users to manually copy-paste or type context [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]. Anthropic identified an opportunity to create mCP to standardize this integration [01:55:00].

mCP is inspired by preceding protocols:

• APIs standardized how web applications interact between front-end and back-end, allowing front-ends access to servers and databases [02:12:00].
• Language Server Protocol (LSP) standardized how IDEs interact with language-specific tools, allowing any LSP-compatible IDE to hook into various coding language features [02:37:00].

Similar to these, mCP standardizes how AI applications interact with external systems [03:10:00].

Addressing Industry Fragmentation

Before mCP, Anthropic observed significant fragmentation in how AI systems were built, both across the industry and within individual companies [03:41:00]. Teams would create custom implementations for integrating AI apps with context, leading to varied prompt logic and inconsistent ways of bringing in tools and data [03:53:00].

The world with mCP aims for standardized AI development [04:15:00]. An mCP client (e.g., Anthropic’s first-party applications, Cursor, Windsurf, Goose) can connect to any mCP server with zero additional work [04:26:00]. An mCP server acts as a wrapper to federate access to various relevant systems and tools, such as databases, CRM systems like Salesforce, or local systems like Git [04:52:00].

Value Proposition of mCP

The adoption of mCP has shown value across the ecosystem [05:33:00]:

• Application Developers: Once an application is mCP compatible, it can connect to any server without extra work [05:42:00].
• Tool/API Providers: They can build an mCP server once and see it adopted across various AI applications [05:51:00]. This flattens the “N times M problem” of numerous permutations for client-server interactions [06:06:00].
• End Users: mCP leads to more powerful and context-rich AI applications, enabling systems that are context-aware and can take actions in the real world [06:28:00].
• Enterprises: mCP provides a clear way to separate concerns between teams. For instance, a team owning infrastructure can build and maintain an mCP server for a vector database or RAG system, allowing other teams to build AI applications faster without needing direct access or custom implementations every time [06:48:00]. This is analogous to the benefits of microservices architectures [07:49:00].

Core Components of the Protocol

mCP standardizes interaction through three primary interfaces [03:17:00]:

1. Tools: These are “model-controlled,” meaning the LLM within the client application chooses when to invoke them [10:27:00]. Servers expose tools with descriptions, and the model decides the best time to use them [10:48:00]. Tools can be used for reading/retrieving data, writing/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]. Servers can define static or dynamic resources (e.g., images, text files, JSON) which the client application then uses as it sees fit [11:31:00]. Resources provide a rich interface beyond simple text-based chat interactions [11:50:00]. In Claude for desktop, resources manifest as attachments that users can select to send to the model, or the model can automatically attach them [12:24:24]. Resources can also be dynamic, interpolated with context from the user or application [20:50:00]. Resource notifications allow clients to subscribe to a resource and be notified when it’s updated by the server [21:17:00].
3. Prompts: These are “user-controlled” and act as predefined templates for common interactions with a specific server [12:56:00]. An example is a slash command in an IDE like Zed that expands into a longer, predefined prompt, which is then sent to the LLM [13:14:00]. Prompts allow teams to standardize interactions like document Q&A or data formatting rules [13:49:00]. Prompts can also be dynamic and customized based on the task at hand [21:08:00].

“The point of mCP is to give more control to each of these different parts of the system as opposed to only just the model itself.” [22:30:00]

Integration of AI into Development Environments and Editors and Applications

mCP has seen significant adoption in applications and IDEs, providing a way for users to provide context while coding [08:21:00]. The agents within these IDEs can then interact with external systems like GitHub or documentation sites [08:34:00].

As of the time of the talk, there were over 1,100 community-built servers published open-source, in addition to servers built by companies and official integrations [08:44:00].

An example of integrating AI into natural workflows with mCP is using Claude for desktop (an mCP client) with a GitHub server [22:52:00]. The user can provide a GitHub repository URL and ask Claude to pull and triage issues [23:13:00]. Claude, using the list issues tool from a community-built GitHub server, can summarize and intelligently prioritize issues based on user context [23:29:00]. It can also autonomously find and add tasks to an Asana project using an Asana server with multiple tools [24:15:00]. These servers are often just a couple hundred lines of code, primarily surfacing tools [24:58:00]. This makes Claude for desktop a central dashboard for managing daily tasks and integrating context from various systems [25:23:00].

Other applications like Windsurf and Goose also demonstrate mCP integration, showing how application builders can decide how to bring mCP context into their unique UIs and agent experiences [25:52:00].

mCP as a Foundational Protocol for Agents

mCP is anticipated to become a foundational protocol for agents broadly, driven by its protocol features and the increasing effectiveness of agent systems and models [26:36:00].

Agents are often conceptualized as an “augmented LLM” running in a loop [28:54:00]. This augmented LLM takes inputs, produces outputs, and uses its intelligence, but is augmented by retrieval systems, tools, and memory [27:29:00]. mCP fits in as the entire bottom layer, making it easier for LLMs to talk to retrieval systems, invoke tools, and incorporate memory in a standardized way [28:10:00]. This means agents can expand their capabilities even after initialization, discovering new interactions without needing to be pre-programmed [28:34:00].

Agent systems, at their core, involve an augmented LLM running in a loop: performing a task, working towards a goal, invoking a tool, analyzing the response, and repeating until the task is complete [28:57:00]. mCP provides these capabilities in an open way, allowing agent builders to focus on the core loop (context management, memory usage, model choice) while users can customize the agent’s interaction with their data [29:47:00].

An example using the open-source mCP Agent framework by Last Mile AI demonstrates this [30:19:00]. An agent can be defined with a task (e.g., research Quantum Computing’s impact on cybersecurity) and given access to mCP servers for web searching (Brave), fetching data (Fetch), and file system access [30:52:00]. The framework allows defining sub-agents (e.g., a “research agent” and a “fact checker agent”) that leverage these mCP servers [31:17:00]. The agent forms a plan (series of steps) based on its task and available servers, enabling it to autonomously perform research, verification, and report generation [33:00:00]. This allows agent builders to focus on the task and agent interactions rather than the intricacies of the servers themselves [33:48:00].

Key Protocol Capabilities for Agents

• Sampling: Allows an mCP server to request LLM inference calls from the client, meaning the server doesn’t need to implement or host its own LLM interactions [53:52:00]. The client owns all LLM interactions, including model preferences, privacy controls, and cost parameters [54:55:00]. This is crucial when clients interact with servers they have never seen before, as it provides a standardized way for the server to request intelligence [55:56:00].
• Composability: An application, API, or agent can act as both an mCP client and an mCP server [56:21:00]. This allows for chaining interactions and building complex, multi-layered architectures where each layer or “agent” specializes in a particular task [57:17:00]. For example, a user talks to Claude for desktop (client + LLM), which calls a research agent (server + client), which then calls various other servers (file system, web search) [56:41:00]. This hierarchical system allows for flexible agent-to-agent communication where agents can have autonomy and make decisions on how to pull in richer data [01:00:10].

The combination of sampling and composability is particularly exciting for agents [01:11:43]. An orchestrator agent can be an mCP server for the user’s client and an mCP client to other specialized agents (e.g., analysis, coding, research agents), all while federating sampling requests back to the primary application controlling the LLM interaction [01:11:50]. This enables hierarchical agent systems that can connect to agents living on the public web while maintaining privacy, security, and control [01:12:35].

Future Developments and Roadmap for mCP

Remote Servers and Authentication (Auth)

A significant development is support for remotely hosted mCP servers and OAuth 2.0 authentication [01:12:28]. This allows servers to live on public URLs and be discoverable [01:15:09]. The server orchestrates the OAuth handshake, getting a callback URL, which the client opens for user authentication. The server then holds the OAuth token and federates future interactions using a session token [01:14:22]. This removes dev experience friction, making mCP servers as accessible as websites, and enables the agent and LLM to live on a completely different system from the server [01:15:30].

mCP Registry and Discovery

A major ongoing effort is the creation of an official mCP registry API [01:22:00]. This unified, hosted metadata service, built in the open, will address challenges with discovering and pulling in mCP servers, which are currently fragmented across various package systems (npm, pip) [01:22:30]. The registry will help with:

• Discoverability: Knowing the protocol for an mCP server (e.g., standard IO, SSE), its location (local file vs. URL) [01:23:12].
• Trust and Verification: Identifying who built a server and if it’s officially verified by a company (e.g., Shopify) [01:23:25].
• Versioning: Providing a log of changes to server capabilities, tools, or tool descriptions [01:24:01].

The registry will enable agents to be “self-evolving” by dynamically discovering new capabilities and data on the fly [01:35:59]. For example, a coding agent could search the registry for a verified Grafana server if it needs to check logs, install or invoke it remotely, and then proceed to fix a bug [01:36:16]. This allows agents to choose their own tools, making augmented LLM systems even more powerful without predefined packages [01:36:56].

Well-Known mCP

Complementing the registry is the concept of a /.well-known/mcp.json endpoint [01:39:24]. This allows service providers (e.g., shopify.com) to provide a verified interface indicating an mCP endpoint exists, its capabilities (resources, tools), and authentication methods (OAuth 2.0) [01:39:30]. An agent can then query this endpoint directly to manage a user’s store [01:39:48]. This provides a “top-down” approach to discovery and verification, working alongside the registry [01:40:07].

This also integrates well with Anthropic’s “computer use” models, which can click around in UIs that lack APIs [01:40:36]. The future envisions agents combining mCP’s predefined API interaction with computer use for long-tail scenarios, creating a powerful blend of structured and unstructured interaction [01:40:52].

Other Medium-Term Considerations

• Stateful vs. Stateless Connections: Exploring short-lived connections for basic client-to-server requests versus long-lived SSE connections for advanced features like sampling and server-to-client notifications [01:41:41].
• Streaming: Supporting first-class streaming of multiple data chunks from server to client over time [01:42:41].
• Namespace: Addressing tool name conflicts when multiple servers are installed, potentially by allowing logical groups of tools [01:42:51].
• Proactive Server Behavior: Developing patterns for servers to initiate actions (e.g., event-driven notifications, requesting more information from the user) rather than solely responding to client requests [01:43:31].

Key Insights from Q&A

• Agent Frameworks: mCP complements agent frameworks like LangChain, providing a standardized way to hook into servers, tools, prompts, and resources without replacing the framework’s core logic (e.g., knowledge management, agentic loops) [01:17:12].
• Proprietary Data: mCP servers can be run within a company’s VPC or on individual employee systems, allowing integration of AI into business operations with proprietary data [01:35:43].
• Tool Limits: Current models can handle around 50-100 tools effectively [01:46:40]. For thousands of tools, strategies like “tool to search tools” (RAG over tools, fuzzy/keyword search) or hierarchical tool systems can be used to manage context [01:47:01].
• Logic Placement: Retrying logic and other business logic should ideally sit on the server side, as the server is closer to the end application and clients may not know server-specific interaction details [01:44:57].
• Debuggability: While the protocol doesn’t enforce specific observability, good servers should expose useful metadata for debugging to provide a good user experience [01:55:00]. Tools like Anthropic’s Inspector help examine server connections and interactions [01:09:49]. LLMs can even auto-generate simpler servers [01:49:21].
• Governance and Security: The server builder controls governance and security, including authorization and authentication, to manage client access to the end application [01:10:56]. The trust of servers will become increasingly important with registries [01:18:28]. Companies can self-host registries to control approved servers [01:37:52].
• Open Source Philosophy: Anthropic intends mCP to remain open, even if it fosters competition among model providers, as it is ultimately beneficial for users and developers [01:28:15]. Claude doesn’t have a specific mCP advantage, but is generally good at tool use and agentic work [01:29:14].
• Transport Agnostic: mCP is transport agnostic. Standard IO is typically used for local/in-memory communication, while SSE is for remote servers [01:32:05].
• Model in Loop: The model does not always have to be in the loop to interact with the server; the client application can deterministically call server functions like call tools or list resources [01:33:07].