MCP Diagram

We have discussed MCP in many previous articles. But recently we received some questions about MCP from readers.

Today I will use two more analogies and then explain MCP from a technical perspective in hopefully 3 minutes.

Analogy 1: Language Learning

Imagine that you only speak English.

• • If you want to get information from someone who only knows French, you must learn French;
• • If you want to get information from someone who only knows German, you must learn German;
• 
  

And so on.

With this way of communicating, even learning only five languages ​​would be a headache!

But what if you had a translator who understood all languages?

You just need to talk to the translator;

It can infer the information you want to know;

It helps you choose who to communicate with;

It can also capture and relay responses for you.

This "translator" is like MCP!

It allows you (the agent) to communicate with other people (the tools) through a unified interface.

In the Agent usage scenario, integrating a single tool or API often means reading documentation and writing adaptation code - just like learning a new language.

To simplify this process, major platforms have launched MCP servers. Developers only need to connect to them, and Agents can immediately use the corresponding tools/APIs.

Analogy 2: USB-C

You can also think of MCP as a USB-C port for your AI application .

Just as USB-C provides a standardized connection method for various devices and accessories, MCP standardizes the connection between your  AI applications and different data sources and tools .

Technology perspective

Implementation Process

MCP is not a hard-coded tool in each application or agent, but is implemented in the following way:

• •  Standardize how tools are defined, hosted, and exposed to LLMs.
• •  Make it easy for LLMs to discover available tools, understand their schema, and use them.
• •  Provide approval and audit workflow before invoking the tool.
• •  Separate the responsibilities of tool implementation and consumption.

Here is a diagram that illustrates the process:

The MCP server displays some tools in the upper right corner. The whole process is as follows:

1. 1. The user sends a query input to the MCP Client, and also transmits the available tool information to the client.
2. 2. The MCP client sends the query along with the tool list to the LLM.
3. 3. Based on the input, the LLM decides which tool to call, with which parameters, and returns the call instructions to the MCP client.
4. 4. The MCP client requests permission from the user to use the tool.
5. 5. After the user approves, the MCP client sends a call request to the MCP server and attaches the call parameters.
6. 6. The MCP server calls the corresponding tool.
7. 7. After the tool is executed, the output is returned to the MCP server, which then forwards it to the MCP client.
8. 8. The MCP client sends the tool output along with the original query to the LLM.
9. 9. LLM generates the final output based on this information.

Why is this important?

Here's an example of the power of this architecture:

Suppose you develop a weather query API.

In traditional API mode:

1. 1. If the API originally required two parameters (such as location and date), users would hardcode these two parameters in their respective applications to send requests.

1. 2. Later, if you add a third required parameter (such as temperature unit: Celsius or Fahrenheit), the contract of the API has changed.

1. 3. This means that all users must update their code to include the new parameters; otherwise, their requests may fail, return errors, or have incomplete results.

Under the MCP architecture:

1. 1. When a client (such as Claude Desktop) connects to an MCP server (such as your weather service), it first sends a "capability query" request.
2. 2. The server returns the currently supported tools, parameters, and descriptions. For example, if only location and date are initially supported, this information will be communicated to the client in the response.
3. 3. If you later add a "Temperature Unit" parameter, the MCP server will dynamically update its capability description during the next capability query.
4. 4.  The client does not need to modify the code, it can recognize and use the new parameters by re-querying the server capabilities at runtime.

In this way, the client can "adapt on demand" and dynamically adapt to the latest tool capabilities without rewriting or redeploying the code.

The above is an introduction to the core functions of MCP.

I hope this article will help you understand MCP!