Anthropic’s Model Context Protocol (MCP) for Tool-Enabled Agentic AI

Anthropic’s Model Context Protocol (MCP) is an open standard for connecting AI models (like large language model assistants) with external tools and data sources. It defines a uniform protocol – analogous to a “USB-C port” for AI – that lets any compliant AI application discover and use tools or data through a common interface . The goal is to replace today’s fragmented one-off integrations with a universal connector. Without a standard like MCP, integrating M AI systems with N tools requires M×N bespoke interfaces; MCP reduces this to M+N by providing a single protocol in the middle . This dramatically simplifies building agentic AI systems that can leverage a wide ecosystem of tools.

Before MCP (left), each AI integration required custom APIs for every tool (Slack, Drive, GitHub, etc.). After MCP (right), AI agents use a unified protocol to access diverse tools .

MCP Protocol Architecture and Design

MCP follows a client–server architecture inspired by the Language Server Protocol (LSP) . It uses JSON-RPC 2.0 for message exchange, enabling a stateful, two-way connection between AI systems and tools . The major components are:

• Host (LLM Application): The AI app or agent environment that initiates connections (e.g. Claude Desktop, an IDE plugin, or a custom AI agent). The host contains one or more MCP clients to manage tool connections .
• MCP Client: A connector running within the host that maintains a 1:1 connection to a specific MCP server . The client speaks the MCP protocol over a transport (HTTP + SSE for remote servers, or stdio for local ones) and mediates communication between the AI model and the tool server.
• MCP Server: A lightweight service that exposes a tool or data source via MCP. Each server provides a standardized interface (using JSON-RPC messages) to offer capabilities – such as data resources or executable tools – to any connected client . The server can run locally (communicating via stdin/stdout) or remotely (via HTTP requests and server-sent events) .

MCP exchanges begin with a handshake to establish a session and negotiate capabilities. The protocol then supports various request/response types for different feature sets . In particular, MCP defines three major categories of features that servers can provide :

• Tools (model-controlled): Functions or actions that the AI model can invoke. Tools are described by a name, a human-readable description, and a JSON schema for input parameters (arguments). They can perform computations, call APIs, modify state, etc. (e.g. “send_email”, “query_database”) . Tools are invoked by the model during a conversation to act on the external system.
• Resources (application-controlled): Read-only data sources that can be retrieved as context. Resources represent static or queryable information (files, database records, knowledge base entries) that the host can fetch for the model . They have unique names and often come with methods to list or read data, but using them does not cause side effects .
• Prompts (user-controlled): Pre-defined prompt templates or workflows that can be injected to guide the model . For example, a server might supply a prompt template for a specific task or a step-by-step script for using its tools. These are selected or provided by the user or system before model inference.

Additionally, MCP supports an advanced feature called Sampling, which allows a server to request the AI to perform a sub-task (i.e. the server can initiate an LLM prompt and get the model’s result) . This can enable recursive agent behaviors (the server asking the model to reason or summarize as part of a tool’s operation), but it is an optional capability with careful guardrails.

Tool Specification and Format

Every tool exposed via MCP has a structured definition. At minimum this includes a unique name and an inputSchema (a JSON Schema object defining the expected parameters) . An optional description helps the AI understand what the tool does. For example, a tool definition might look like:

{
    "name": "calculate_sum",
    "description": "Add two numbers together",
    "inputSchema": {
        "type": "object",
        "properties": {
            "a": {
                "type": "number"
            },
            "b": {
                "type": "number"
            }
        },
        "required": [
            "a",
            "b"
        ]
    }
}

The JSON schema makes it explicit what inputs the tool accepts (here two numbers an and b). MCP also allows annotating tools with metadata hints like readOnlyHint, destructiveHint, etc., to indicate if a tool modifies data, has side effects, is idempotent, or interacts with external systems . These annotations can be used by the host to inform users or enforce safety (e.g. requiring extra confirmation for a destructive action).

On the server side, implementing a tool means handling two core RPC endpoints: one for discovery and one for execution . The MCP spec defines: - tools/list: The client requests the list of available tools. The server responds with an array of tool definitions (as shown above) . This allows the client (host) to discover what actions the server can do. - tools/call: The client calls a specific tool by name, providing a JSON object of arguments that match the tool’s input schema. The server executes the corresponding operation and returns a result payload (often formatted as content for the model to read) .

Example: In a TypeScript MCP server, one could register a tool “calculate_sum” like so – on tools/list return the tool’s schema, and on tools/call perform the addition:

server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: "calculate_sum",
        description: "Add two numbers",
        inputSchema: {
          type: "object",
          properties: {
            a: { type: "number" },
            b: { type: "number" }
          },
          required: ["a", "b"]
        }
      }
    ]
  };
});

server.setRequestHandler(CallToolRequestSchema, async (req) => {
  if (req.params.name === "calculate_sum") {
    const { a, b } = req.params.arguments;
    return {
      content: [
        {
          type: "text",
          text: String(a + b)
        }
      ]
    };
  } else {
    throw new Error("Tool not found");
  }
});

In this snippet, the MCP server exposes the tool and handles the addition logic. The returned result is packaged as a piece of text content (one possible format) that the model can later read as the outcome . The MCP client/host doesn’t need to know these implementation details – it will discover the tool and let the model invoke it as needed.

How MCP Enables Tool Use in Agentic AI Workflows

The MCP protocol is designed to let an AI agent seamlessly find and use tools at runtime. Here’s an outline of how an agentic AI system would utilize MCP in practice:

1. Initialization: The host application (AI agent) starts up and spawns or connects to one or more MCP servers. For each server, it opens a session via an MCP client, performing a handshake to establish a JSON-RPC connection and exchange capability info (e.g. protocol version, supported features) . This sets up a persistent channel to each tool/service.
2. Discovery of Tools/Data: The agent queries each connected server for its available capabilities. For example, it sends a tools/list request and receives the list of tool definitions (with names, descriptions, schemas), and similarly fetches any resource lists or prompt templates the server offers . Now the agent program knows what tools (functions) exist on each server, and what inputs they require.
3. Context Integration: The host can now integrate this knowledge into the model’s context. This may involve providing the model with descriptions of the tools or directly registering them in the model’s interface. For instance, if using an LLM API that supports function calling, the host can take the JSON schemas from the MCP server and supply them as available functions to the model . Any static resources needed might also be retrieved and given to the model as context. Essentially, the agent “plugs in” the server’s capabilities for the model to use during its reasoning process.
4. Invocation (Model-driven): During the conversation or task, when the AI model decides it needs a certain functionality, it will invoke the corresponding tool. In practice, a capable LLM will output a structured function call indicating which tool to use and with what arguments (e.g. {“name”: “calculate_sum”, “arguments”: {“a”: 5, “b”: 7}}). This is analogous to OpenAI’s function calling mechanism – the model’s response includes a function name and parameters . The host intercepts this and translates it into an MCP action by sending a tools/call request to the appropriate MCP server . For example, if the model chose “calculate_sum”, the client issues tools/call on the server that advertised that tool, passing the JSON {a:5, b:7}.
5. Execution and Result: The MCP server receives the call, executes the underlying function or API, and returns the result to the client. The result might be a simple value (e.g. the sum “12”) or a complex payload (e.g. a JSON with search results, or even a stream of data). The MCP client then conveys this result back to the model. Typically, the host will insert the result into the conversation in a sensible way – for instance, as the assistant’s next message containing the tool output. The model can then continue the dialogue with that fresh information in mind . Because the MCP connection is stateful, the server could also maintain context if needed (for example, caching previous queries or keeping a database connection open for efficiency). At this point, the tool’s effect (the calculation, API call, etc.) is complete and the agent can formulate the final answer for the user incorporating the result.

Throughout this process, human oversight and approval can be layered in. MCP is designed with user consent in mind – the host application can require the user to approve a tool invocation before actually executing it . For instance, Claude’s interface may prompt “Allow AI to use database.query tool?” giving the user control. The protocol itself includes no user interface, but it provides guidelines (and metadata like the destructiveHint) to facilitate safe tool use in the agent UI .

In summary, MCP separates what the AI decides to do from how that action is executed:

• The LLM decides which tool to call and with what arguments (often via its internal reasoning or a prompt-based function call) .
• The MCP layer takes care of locating the right service and performing the action in a standard way, returning results back to the model .

This design allows complex tool-using behavior to be built in a composable way. New MCP-compliant tools can be added to the system without retraining the model or writing custom integration code for each tool – as long as the model can understand a generic function/tool call format, it can use any tool advertised via MCP. Anthropic’s Claude models (v3.5 and above) natively support function-style tool use, which fits perfectly with MCP’s approach of dynamic tool discovery and invocation .

Practical example: One developer demonstrated an agent using Claude-3.5 that connects to a custom MCP server for a count_letters function. The agent programmatically: (a) launches the MCP server, (b) fetches its tool list, (c) passes the tool’s JSON schema into Claude’s API call, and then (d) when Claude returns a function call asking for count_letters(“Strawberry”,“R”), the agent calls the MCP server to execute it and gets the result back – which Claude then uses to answer the user . The final response was: “There are 3 ‘r’s in the word ‘Strawberry’.”, with the heavy lifting (counting) done by the external MCP tool . This illustrates how MCP lets an AI utilize external code on the fly, with the agent code only needing to orchestrate the connection and data flow.

Advantages of MCP vs. Other Tool-Use Frameworks

MCP is emerging as a standard interface for tool-using AI, and it brings several technical advantages over more proprietary or ad-hoc approaches (like OpenAI’s function calling or library-specific agent frameworks):

• Open and Model-Agnostic: MCP is not tied to a single AI vendor or model. It’s an open specification (backed by Anthropic) that any developer can implement . This means any LLM – Claude, GPT-4, PaLM, open-source models, etc. – can potentially use MCP to access tools, given the proper prompting or function-calling support. In contrast, OpenAI’s function calling is a feature specific to OpenAI’s API, and ChatGPT Plugins require OpenAI’s ecosystem. MCP’s openness has led to a fast-growing community: by early 2025 there were over 1,000 community-built MCP servers (tools/connectors) available , making it increasingly likely to become a de facto standard across the industry .
• Loose Coupling & Reusability: With MCP, tools are decoupled from the agent implementation. Each tool is an independent service (MCP server) with a self-contained definition of its capabilities. The agent doesn’t need hard-coded knowledge of how to call that tool beyond the standard protocol. This yields more maintainable and modular systems . For example, if a tool’s API changes or a new version of a database is used, the MCP server can be updated in isolation – the agent interface remains the same. OpenAI’s function calling, by comparison, often involves writing function stubs or code in the same codebase as the agent, creating tighter coupling. LangChain-style agents similarly require integrating new tools by writing Python classes or wrappers for each, which is within that specific framework and not easily shareable. MCP servers, on the other hand, can be distributed and used by different teams or products. In fact, one MCP server (say for a calendar API) can be plugged into many different AI applications (clients) with no changes .
• Dynamic Discovery: MCP enables dynamic tool discovery at runtime. An AI agent can automatically detect what tools (MCP servers) are available and adjust accordingly . If a new MCP server is added (for a new data source), the running agent can list it and utilize it immediately via the protocol – analogous to how a computer recognizes a newly plugged-in device. Traditional function calling or agent frameworks lack such a standard discovery mechanism; usually tools must be pre-registered in code. This dynamic, plug-and-play quality is crucial for scalable agentic systems, where you might want to flexibly add or remove tool integrations without redeploying the entire agent.
• Rich Interaction Capabilities: MCP’s protocol provides for more than just single-step function calls. Because it is stateful and uses JSON-RPC, it supports features like streaming responses, intermediate progress updates, cancellations, and error reporting in a standardized way . For example, a tool that streams data (like reading a large file or a long computation) can send incremental results via the SSE channel, and the client can relay those increments to the LLM or UI. OpenAI’s function calling is stateless per API call and doesn’t have a built-in notion of streaming a function result (aside from the model’s token streaming, which is different). Likewise, LangChain agents typically handle tools in a turn-by-turn textual interaction, whereas MCP provides a formal API layer for tool execution, which can be more robust. MCP also allows multi-turn conversational tools (via the Sampling feature) where a server can engage the model in its own mini-dialogue if needed – something beyond the scope of simple function call frameworks.
• Security and Governance: While tool use always carries risks, MCP puts an emphasis on explicit user control and safety in its design. It standardizes the way an agent should ask for user permission and how tools should declare potentially dangerous actions. For instance, the protocol suggests that a host “must obtain explicit user consent before invoking any tool” and that UIs should clearly show what data is being shared . Other frameworks like raw function calling don’t dictate these practices, leaving it up to each implementation. MCP’s consistent approach to trust and safety can make it easier to build secure agentic applications (though it’s still up to developers to follow the guidelines).
• Ecosystem and Compatibility: MCP is already being integrated into other frameworks and platforms, illustrating its flexibility. For example, there are adapters to use MCP tools within LangChain agents , meaning developers can leverage the growing catalog of MCP servers from a LangChain-based project instead of writing new Tool classes. Anthropic’s Claude and Amazon Bedrock have built-in support for MCP connectors, and even IDEs like VS Code (via extensions) are adding MCP client support to let the AI assistant access local files or git repos securely. This cross-compatibility is a strong advantage over proprietary solutions – an OpenAI Plugin is only usable in ChatGPT, but an MCP server could be used by ChatGPT (if OpenAI chose to support it) and by Claude, and by a local agent, all through the same interface.

In summary, OpenAI’s function calling feature can be seen as complementary to MCP: function calling is how the model formats a tool request (Phase 1), whereas MCP is how that request is executed against an external system (Phase 2) . OpenAI’s approach by itself is limited to the functions you wire up in your code; MCP generalizes this by providing a network of available functions (tools) that any model can tap into. LangChain agents provide higher-level orchestration (planning which tool to use, handling multi-step reasoning), and indeed LangChain can sit on top of MCP – using MCP as the backend for actual tool execution. But without MCP, each LangChain tool is a one-off integration; MCP makes those tools reusable across projects.

Implementation and Developer Resources

MCP is designed to be developer-friendly. The protocol specification (with TypeScript schema definitions) is open-source , and Anthropic provides SDKs in multiple languages (Python, TypeScript/Node, Java, Kotlin, C#) to simplify building MCP clients or servers . There are reference server implementations for many common tools and platforms – for example, Anthropic’s open repository includes MCP servers for file systems, SQL databases, Google Drive, Slack, GitHub, web browsers, and more . Developers can use these out of the box or as templates for their own connectors. Early adopters like Block (Square) and Sourcegraph have built custom MCP servers to let AI assistants interface with their systems , and the community is rapidly expanding the list of integrations available.

Getting started with MCP typically involves running an MCP server for the tool or data you want the AI to access, and then configuring your AI application (client) to connect to it . For example, to allow an AI agent to use a company’s internal knowledge base, you might deploy an MCP server that indexes the knowledge base and exposes a search tool and a get_document tool. Your AI agent (client) would connect to that server (maybe via a secure HTTP endpoint), discover those tools, and then the model could call search when the user asks a question – retrieving relevant docs in real time. Because MCP servers can be hosted internally, they allow sensitive data to remain behind your firewall; the model only sees what it’s allowed to see via the protocol. This aligns with MCP’s emphasis on data security and privacy (hosts should not send data to a model without consent) .

Developers have shared numerous tutorials and examples of MCP in action. Anthropic’s official documentation site (modelcontextprotocol.io) provides a quickstart guide, code samples, and even an interactive “inspector” tool for testing MCP calls. Community blogs and resources (e.g. Neo4j’s example of using Claude with an MCP server for graph database queries , or Medium tutorials on building MCP servers in Python ) offer further insight into real-world usage. As of 2025, MCP appears to be gaining momentum as a cornerstone for building agentic AI systems that are extensible, tool-aware, and production-ready. By adhering to a common protocol, AI developers can share and reuse integrations, focus on higher-level agent logic, and trust that their tools can work across different AI models and platforms with minimal friction.