MCP Model Context Protocol

Tool calling solves the matter of "how the model expresses that it wants to call a tool", but it does not answer another more practical question: how can thousands of tools and data sources be connected to various AI applications in a standardized way?

Without a unified standard, the situation is pairwise customization. Suppose there are M AI applications and N tools or data sources; for each application to use each tool, a separate integration logic must be written, so M×N custom integrations are needed in total. As applications and tools multiply, this number expands rapidly: for tool providers, each new application requires another integration; for application providers, each new tool also requires rewriting the integration. Both sides are reinventing the same wheel.

The diagram makes this contrast clear: on the left is the situation without a standard, where M applications × N tools equals M×N pairwise custom integrations, with messy connections that are hard to maintain; on the right, after introducing MCP as a unified interface, each application and each tool only needs to connect to MCP once, and they can interoperate. The number of integrations drops from M×N to M+N.

So what MCP really solves is the problem of "repeatedly writing connection adapters between different AI applications and tool providers." Its input is M applications and N capability sources; its output is a connection structure in which both sides implement the common protocol only once and can then interoperate. The ideal number of integrations changes from M×N to M+N. Here M+N means the connection code can be reused, not that each specific combination no longer needs to handle authentication, authorization, versioning, and semantic adaptation—those are still tasks to face for every concrete connection, but at least it is no longer necessary to rewrite the adapter layer from scratch for every pair.

MCP is an open standard protocol: it specifies "how tools and data sources expose themselves" and "how AI applications connect to and use them".

This positioning can be understood through two familiar analogies. It is like USB-C—no matter what device or cable, as long as you recognize this port, you can plug it in, unifying the charging and data interface; and like HTTP—unifying the way browsers and websites communicate. The common point is: once a set of interfaces is defined, both sides implement the standard once and can interoperate, without needing pairwise customization for every pair.

Returning to the previous section's M×N and M+N: if the tool side implements an MCP Server once, such as the official GitHub Server, it can be used by all MCP-enabled applications; if the application side implements an MCP Client once, it can connect to the tools across the entire MCP ecosystem. Thus, adding a new tool costs "＋1" rather than "×M".

Therefore, MCP is essentially an open protocol that specifies how capabilities are exposed, discovered, and invoked. Its inputs are the application side and server side that implement MCP, and its outputs are structured messages and a lifecycle that can interoperate. The two boundaries to maintain are: like USB-C, it unifies the interface without doing the device's work for it; protocol compatibility only means that the two parties can exchange messages and does not guarantee that a particular tool is real, safe, or suitable for the current task.

Tool calling and MCP are two different layers and need to be viewed separately.

Tool calling solves a problem at the model level: how the model expresses "I want to call this tool". MCP solves a problem at the connection level: how tools and data are exposed in a standard way and how applications connect. As an analogy, tool calling is the act of "ordering," while MCP is the unified "menu format + kitchen interface" standard.

Another way to put it more plainly: tool calling tells you "the model can order," while MCP tells you "all restaurants make their menus and kitchens according to the same standard, so any assistant that can order can walk into any restaurant and order directly". The former is a capability; the latter is a standard that makes that capability scalable and reusable.

So the two are not substitutes but complements: MCP still uses tool calling underneath, and what it standardizes is only "where tools come from and how they are connected". The overall division of labor can be described as follows: the input is the tool intent expressed by the model and the connection to external capabilities, and the output is the tool-calling layer and the MCP connection layer. The model uses tool calling to express "what it wants to do", while the Host discovers and requests "who does it and how" through MCP. The two layers must work together for actual execution; MCP will not choose tools for the model, and tool calling does not solve the problem of cross-provider integration and reuse.

In one MCP connection there are three roles; once you distinguish who is who, the whole thing becomes clear.

Host (host) is the application that runs the model and faces the user, such as Claude Desktop, some IDE, or some Agent. Client (client) is the connector inside Host responsible for connecting to a particular Server; you can understand it as the "plug" in Host that connects to GitHub Server. Server (server) is the party that exposes the capability of a certain tool or data source, such as GitHub Server, database Server, file system Server.

The relationship among the three is: one Host can contain multiple Clients, and each Client connects to one Server. To add another tool, add a Client in Host to connect to its Server—plug and play. The details of the three roles and transport methods belong to the MCP architecture node; here we first grasp the division of work.

A Server usually exposes three kinds of things: tools are callable operations, resources are readable context, and prompts are user-selectable templates. Their controlling subjects differ—tools are often up to the model to decide whether to invoke, resources are managed by the application, and prompts are usually explicitly selected by the user.

Also note that the connection is not "plug in and call directly." The Client and Server first complete the initialize handshake using JSON-RPC, negotiate the protocol version and capabilities of both sides, and only then enter a normal session; locally stdio is commonly used, and remotely Streamable HTTP is commonly used. Only capabilities declared during negotiation should be used, and lifecycle and errors must also be handled according to the protocol.

To summarize, the inputs of this group of roles are the user session, a single Server connection, and service capabilities; the outputs are the respective responsibilities of Host, Client, and Server, as well as the lists of tools, resources, and prompts. Host manages users and policies; each Client maintains a Server session; Server exposes focused capabilities. The role relationship describes communication boundaries and does not mean that Server has already gained all sessions, resources, or execution permissions.

Walking through "connecting to a weather Server and checking the weather in New York" from start to finish makes it clear how the protocol turns capabilities into a discoverable, verifiable sequence of messages—while also making it clear that the protocol itself does not decide authorization on behalf of the Host.

The first step is initiating the handshake: the Client sends initialize to the Server, declaring the protocol version, Client information, and supported capabilities. The second step is the negotiation result: the Server replies with InitializeResult, selects the protocol version, and returns Server information and its supported capabilities. The third step is handshake completion: the Client sends notifications/initialized, confirms that initialization is complete, and both parties enter a normal session. These three steps address the question of "whether the two parties can communicate, and with which protocol version."

The fourth step is capability discovery: the Client sends tools/list and obtains the tool names, descriptions, and input schema—for example, get_weather(city). The fifth step is initiating the call: the Client sends tools/call; at this point the Host has already selected the tool and validated the parameters, and then it sends {city: "New York"}. The sixth step is processing the result: the Server returns the call result, the Host marks the source, checks for errors, and then decides which content enters the model and which actions require user confirmation.

Here are several key boundaries. Capability negotiation only says "what both parties can do," not "what the user authorizes them to do": even if the Server declares tools for writing files or sending messages, the Host should still independently perform permission checks; tool return values are also external data, and they do not automatically become trustworthy just because they went through Model Context Protocol (MCP). If you view the protocol as a state machine, you cannot arbitrarily invoke tools before initialization is complete; after tools are discovered, the model only proposes candidate invocations; before actual execution, parameter validation, permission, and consent checks are still required. In other words, MCP specifies message exchange, and the Host retains final control.

The input to the entire weather example is the version capabilities of both parties and the city parameter, and the output is the negotiated session, the tool catalog, and the result with its source. The Client first completes initialize, then confirms initialized, and then performs tools/list; after that, the Host validates and authorizes tools/call. The returned weather only indicates that the Server produced a result; capability negotiation does not equal user authorization, and error information or external text is still treated as untrusted data.

After interfaces are unified, the AI tool ecosystem undergoes three substantive changes.

First, tools are reusable. Tool providers implement an MCP server once, and any Host compatible with the same core primitives, transport, and authorization conditions can reuse it, with no need to rewrite it pairwise for each application.

Second, applications are extensible. Once an Agent supports MCP, it can connect to compatible servers on demand; actual usability still depends on protocol versions, authentication and authorization, and extension capabilities.

Third, composability. By combining file system, database, and browser servers, the same Agent can collaborate across systems to complete complex tasks.

Taken together, why are these three a big deal? Because they turn "connecting tools to AI" from a one-off custom job into a cumulative public ecosystem—just as, once the USB standard existed, peripheral manufacturers and computer manufacturers no longer had to adapt to each other pairwise. This is one of the key pieces of infrastructure enabling AI applications to quickly grow "hands and feet", so it is marked as an active direction under evolution.

Looking at ecosystem standardization as a whole, the input is multiple compatible Hosts and Servers, and the output is a reusable, extensible, and composable capability network. A newly added party only needs to implement the common interface to be discovered by compatible parties, and cross-system tasks are orchestrated by the Host. At the same time, remember that M+N is an ideal reuse intuition; extension differences, protocol versions, authentication, and business semantics can still limit actual interoperability.

"Plug and play" is very satisfying, but connecting to external Servers also introduces new trust issues, and the cost must be taken seriously.

First, the Server itself may not be trustworthy. A malicious or compromised Server may abuse the permissions granted to it, or return misleading content, so the principle is to connect only to Servers you trust.

Second, tool results may contain Prompt Injection. Content returned by the Server enters the model's context; if malicious instructions are hidden within, it may hijack the model into calling other dangerous tools. This is connected to the issues described in Section 6 on Prompt Injection and tool calling.

Third, permissions and authorization. Access permissions granted to the Server should follow the principle of least privilege; for high-risk operations, human-in-the-loop confirmation is still required.

More importantly, the standard lowers the barrier to integration, and simultaneously lowers the barrier to "integrating bad things." Precisely because it is "plug and play," we must be even more vigilant about "what is being plugged in." MCP solves "how to connect," but it does not judge for you "whether you should connect, or how much permission to grant once connected."

Therefore, MCP security governance takes as input the Server's identity, required resources, tool risks, and returned content, and outputs connection permission, least privilege, per-use authorization, or denial. The Host must validate subjects, parameters, and side effects outside the model, and external results should preserve their source and isolate Prompt Injection. Also remember that even a trusted Server may be compromised; protocol compatibility and one-time approval cannot replace continuous authorization and auditing.

Linking "why standardize" all the way to "why the protocol cannot replace authorization" lets you check where each conclusion comes from.

Tool calling lets the model "place orders," but it doesn't solve "how thousands of tools can be connected to various applications in a standardized way" (§1). Without a standard, there are M×N pairwise custom integrations, which explode with scale (§1). Thus Model Context Protocol (MCP) appeared as an open standard, like USB-C for the AI world: each side implements the standard once to interoperate, reducing M×N to M+N (§2).

MCP and tool calling belong to two distinct layers—one is a model capability, the other is a connection standard—while under the hood MCP still uses tool calling (§3). A connection has three roles: Host (application), Client (connector), Server (exposes tools, data, and prompts) (§4). The connection first goes through initialization, capability negotiation, discovery, and invocation; the protocol specifies message order, and the Host is responsible for authorization and handling results (§5). Standardization makes tools reusable, applications extensible, and capabilities composable, thus forming a public ecosystem (§6). But connecting to an external server also introduces trust issues: malicious servers, prompt injection in tool results, and permission management (§7).

Therefore, the takeaway of the entire chain is: standardization solves "how to connect," but authorization and security remain the Host's independent responsibility. If you can clearly explain "why MCP turns M×N into M+N" and say "which layer it and tool calling each solve," you have grasped the core of MCP.

You can arrange the order of learning this page according to dependency levels.

The prerequisite concepts include: Tool Calling / Function Calling, large language models, and AI Agent. These three form the foundation for understanding MCP—only after knowing that models can "call tools" can one understand what MCP standardizes on top of tools.

The core concepts of this page are: open standard, M×N→M+N, the three roles of Host/Client/Server, and the three types of capabilities: tools/resources/prompts.

The adjacent extension concepts are: MCP Architecture, AI Agent, Agent Loop, Prompt Injection, and Human-in-the-loop. Among them, MCP Architecture supplements the transport and protocol details of the three roles, while Prompt Injection and Human-in-the-loop directly take up the trust issues raised in the security section of this page.

Further extension directions include: Agent Skills, Context Engineering, Multi-agent Orchestration, and Computer Use. These are larger topics that gradually unfold only after mastering a single connection standard.