Overview

With the rise of intelligent programming tools such as Cursor, the launch of Manus products, and the significant improvement of the programming capabilities of large language models such as Claude Sonnet, MCP has gradually attracted widespread attention and attention from the technical community. This article will introduce the core concepts of MCP in an easy-to-understand manner and explore its practical application value in combination with specific scenarios.

What is MCP?

MCP (The Model Context Protocol) is an open protocol proposed by Anthropic in November 2024. MCP enables seamless integration between LLM applications and external data sources and tools. Whether building an AI-driven IDE, enhancing the chat interface, or creating a custom AI workflow, MCP provides a standardized way to connect LLM with the required context.  MCP can be understood as a connector for the Agent world .

MCP overall architecture

MCP follows the client-server architecture. For one Agent, it can connect to multiple MCP Servers. The overall architecture consists of 4 parts:

• MCP Host: Programs for AI tools that access data through MCP, such as Claude Desktop, Integrated Development Environment (IDE), or Agent
• MCP Client: A protocol client that maintains a 1:1 connection with the MCP Server
• MCP Server: A lightweight program that exposes specific functions through standardized MCP, including tools, external resources, and prompt templates.
• MCP Protocols: defines the communication method between MCP Client and MCP Server

MCP Host

MCP Host can be any LLM application/agent that needs to access external data. They are responsible for:

• Initialize and manage multiple MCP Clients.
• MCP Client-MCP Server lifecycle management.
• Handles user authorization.
• Manages context aggregation across MCP Clients.

MCP Client

Each MCP Client is responsible for:

• Dedicated connection: Each MCP Client maintains a one-to-one stateful connection with the MCP Server. This dedicated connection mode ensures clear communication boundaries and achieves secure isolation.
• Message Routing: The MCP Client is responsible for handling all two-way communications, efficiently delivering requests, responses, and notifications between the MCP Host and the connected MCP Server.
• Capability management: The MCP Client monitors and manages the capabilities of the connected MCP Server by maintaining information such as the server's available tools, resources (context data), and prompt templates.
• Protocol negotiation: During the initialization phase, the MCP Client negotiates the protocol version and related capabilities with the MCP Server to ensure compatibility between the MCP Host and the MCP Server.
• Subscription management: The MCP Client maintains the subscription relationship with the MCP Server resources and is responsible for processing and distributing the corresponding notification events when these resources change.

MCP Server

MCP Server is the basic building block that provides external data and context for LLM. The key components of MCP Server include:

• Tools: Tools are executable functions that enable the LLM to interact with external applications, similar to functions in traditional LLM calls. For example, a tool called LIST_FILES A tool receives a directory name as a parameter, gets the files in the directory after execution, and returns the result to the client. In addition, a tool can also be an API call to an external service, such as Gmail, Slack, and Notion.
• Resources: Resources include text files, log files, database structure definitions, file contents, and Git history, which can provide additional contextual information for LLM.
• Prompt Templates: Predefined templates or instructions that guide the interactive behavior of LLM.

Tools are controlled autonomously by the model, while resources and prompt templates are controlled by the user. The model can automatically discover and invoke the required tools based on the given context.

MCP Protocols

All MCP Protocols must comply with JSON-RPC 2.0. The types currently defined by the protocol are:

• Requests: Messages for executing operations, which must contain a unique ID and method name.
• Responses: The returned message must include the ID in the Request.
• Notifications: One-way messages do not need to be returned and must not contain an ID.

For more information about the protocol, please refer to: https://spec.modelcontextprotocol.io/specification/2024-11-05/

Function Calling vs MCP

The main differences are as follows:

Function Calling is a feature introduced by specific large model service providers (such as OpenAI's GPT-4). It allows the model to generate a function call request in a specific format based on the input. After receiving the request, the application performs the corresponding operation and returns the result to the model. This mechanism enables the model to actively request the execution of external functions, but does not require the use of a specific communication protocol or format.

MCP was proposed after OpenAI's Function call and GPTs. It can be said that Function call provided inspiration and basic functions for MCP. MCP is an open protocol that aims to achieve seamless integration of large language models with external data sources and tools through standardized interfaces. It specifies the structured delivery of context and requests to ensure the standardization and consistency of message delivery. The original intention of MCP was to ensure the security of user data by running servers locally and avoid sending sensitive information directly to LLM.

Main differences:

• Hierarchical positioning: Function Calling focuses more on the specific implementation and characteristics of the model, and is a unique function provided by a specific large model manufacturer. MCP is a lower-level and more universal standard, equivalent to a "public infrastructure" provided to everyone.
• Communication method: The communication format of Function Calling is not fixed and may vary depending on the implementation of different manufacturers. MCP requires the communication format to follow the JSON-RPC 2.0 standard to ensure the standardization and consistency of message transmission.
• Dependency: The two do not include each other, and neither must depend on the other. Applications can choose to interact with the model through specific mechanisms (including Function Calling) on ​​MCP, or use other methods not based on Function Calling to interact with the model or data source under the MCP paradigm.