An easy-to-understand introduction to MCP concepts

What is MCP?

MCP was very popular some time ago, and I wanted to take advantage of the popularity to publish a few related articles, but it was delayed for various reasons, and I didn’t get to take advantage of the popularity.

But there are also advantages. When we look at MCP now, at least we won’t be led by popularity.

At the end of November last year, Anthropic (the AI ​​company that Claude founded) open-sourced the MCP protocol (Model Context Protocol), which is:

• An open protocol, like a USB interface for AI applications, standardizes how applications provide context to the LLM.
• A standardized bridge between AI applications and different data sources and tools;
• Enable developers to create secure, two-way connections between their data sources and AI-driven tools;
• The goal is to help cutting-edge models generate better, more precise responses.

To put it simply, we can understand it as an adapter, which can be plugged into network cables, external monitors, power cables, other USB-enabled devices, etc.

• The computer is the Host, corresponding to AI applications that support MCP, such as Cursor and Claude Desktop.
• The adapter is the MCP, and the interface on the adapter is the MCP Client, which has a one-to-one correspondence with the MCP Server.
• The external mobile hard disk, monitor, network cable, etc. is the MCP Server.

Why do we need MCP?

It is important to know that the training data for each model is different, and the model itself cannot update its internal data autonomously.

This results in even the most sophisticated models being limited by their isolation from the data, ultimately trapped in information silos and legacy systems.

Each new data source requires a separate custom implementation, making truly connected systems difficult to scale.

Until the emergence of MCP, the above problems were solved.

In fact, OpenAI has previously introduced the concept of a Function call. Using Function call, we can break the barriers between AI models and external data, thereby realizing AI networking, weather access, and other functions.

This also made me wonder when MCP first came out, why should we come up with something "same" as Function call when Function call can also do it?

When OpenAI also used this protocol and made it really popular, they found that it was not that simple.

First , we’ve said that MCP provides a common open standard for connecting AI systems and data sources, replacing fragmented integration with a single protocol.

In the MCP architecture, the host (the MCP client's host) application can connect to multiple servers:

Here are some concepts to explain: - The host is the LLM application that initiates the connection (such as Claude Desktop or Cursor); - The client maintains a 1-1 connection with the MCP server inside the host; - The server provides context, tools and prompts to the client;

Secondly, before MCP is released, if an AI application wants to connect to some tools, it may need to do separate adaptation within the application, which will lead to business complexity and coupling.

After MCP came out, it converged this complexity and coupling through unified specifications:

• The tool provider provides the MCP Server
• AI applications use the MCP Client to connect to the Server

Finally, and most importantly, MCP is a protocol, not an API. As its full name suggests, the Model Context Protocol.

It is a standardized and normalized thing, while API tends to be customized. If any changes occur, it will easily cause the functions of the docking party to fail.

MCP also has three core types of functions: Tools, Resources, and Prompts. I won’t go into details here. If you are interested, you can visit their documentation to learn more.