ArthurChiao's Blog

But What Is MCP (Model Context Protocol)? (2025)

Published at 2025-03-23 | Last Update 2025-03-23

There are already some good documents for MCP,

but developers and architects may still feel confusing on how it works in the underlying, and this post try to fill the gap.

Fig. Integrate external services to AI applications with MCP. Note that MCP also supports connecting to local services (co-located with the AI application) with the same client-server architecture.



1 What’s MCP?

1.1 Naming

MCP is an abbreviation for Model Context Protocol. From the name, we can see that

  • First of all, it’s a communication protocol,
  • Then, it’s for models (LLMs),
  • At last, it is used for exchanging/passing model context.

1.2 Why MCP?

When building agents or complex workflows on top of LLMs, it is often necessary to integrate with external data or tools (e.g. external MySQL, Google Maps). MCP provides a standardized way to do this.

Let’s use an analogy to better explain it.

1.3 Analogy

Traditionally, personal computers have a variety of hardware connectors, such as USB, HDMI, DP, RJ45, etc.

Various kinds of hardware connectors.Image Source

Computer designers have to decide what devices that they would like to support during the design phase, and then pre-install the corresponding hardware interfaces on the motherboard. When new kinds of hardware connectors come in, it’s impossible to support them without changing the motherboard, or introducing new kinds of hardware adapters.

1.3.1 USB type-c for computer

With the introduction of USB type-c specification, things have changed. USB type-c is becoming the standard connector for most devices. As illustrated below,

Fig. Peripheral devices connected to a computer's USB type-c hub with adapters.

When the computer needs to connect to many peripherals, it first plugs in a USB type-c hub (the actual hub generally supports multiple interfaces, not just type-c), and for those peripheral devices,

  • If they are already of type-c, they can connect to the hub directly;
  • Otherwise, such as they are some old devices or professional devices in specific fields, they can be converted to type-c through a adapter first, then connecting to the hub.

So, as long as a device supports (directly or through a converter) the type-c interface, it can be easily integrated to the computer.

1.3.2 MCP for AI Apps

MCP is like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools.

An analogy is shown below,

Fig. Integrate external services to AI applications with MCP. Note that MCP also supports connecting to local services (co-located with the AI application) with the same client-server architecture.

From the left to right,

Personal Computer case AI App case Notes
Peripherals, such as monitors External data or services, such as Google Translate To be integrated into the AI application. They may use various protocols, such as HTTP, WebSocket, gRPC, Redis protocol, etc.
Connector adapters Protocol adaptation layer (server-side) One MCP server for each external service, providing a standardized interface (JSON-RPC) to the MCP client.
USB type-c hub Protocol adaptation layer (client-side) One MCP client for each external service, connecting the corresponding MCP server with standard protocol.
The personal computer The AI app The main part, integrate external services with the MCP clients.
  LLM layer AI apps rely on LLM services for function calling to the external services with MCP.

1.4 Summary

MCP is an open protocol that standardizes how applications provide context to LLMs. Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools.

2 Architecture & Spec

MCP follows the classic client-server architecture.

2.1 Base Protocol

  • JSON-RPC message format
  • Stateful connections
  • Server and client capability negotiation

2.2 Server side

MCP Primitives

The MCP protocol defines three core primitives that servers can implement:

Primitive Control Description Example Use
Prompts User-controlled Interactive templates invoked by user choice Slash commands, menu options
Resources Application-controlled Contextual data managed by the client application File contents, API responses
Tools Model-controlled Functions exposed to the LLM to take actions API calls, data updates

Server Capabilities

MCP servers declare capabilities during initialization:

Capability Feature Flag Description
prompts listChanged Prompt template management
resources subscribe listChanged Resource exposure and updates
tools listChanged Tool discovery and execution
logging - Server logging configuration
completion - Argument completion suggestions

2.3 Client side

Clients may offer the following feature to servers:

  • Sampling: Server-initiated agentic behaviors and recursive LLM interactions

MCP client gets the server’s capabilities through APIs such as list_tools.

Note that LLM is only responsible for selecting functions, the actual function calling is triggered inside the AI app.

2.4 Programming examples

  • https://modelcontextprotocol.io/quickstart/client
  • https://github.com/modelcontextprotocol/python-sdk

3 Function Call vs. MCP

Conceptually, MCP and Function call are both for AI applications to easily call external services, but their work in different ways. Let’s take a look at the workflow of a specific example —— accessing the Google Translate API —— and see the difference between these two methods.

3.1 Function Call

Fig. Function call workflow for accessing Google Translate.

Steps:

  1. AI app: build prompt, include the function information of the Google Translate API in the prompt;
  2. AI app: call LLM with the prompt;
  3. LLM: model response, with the selected function included;
  4. AI app: calling into the Google Translate API with (HTTP/HTTPS);

3.2 MCP

The same scenario for MCP:

Fig. MCP workflow for accessing Google Translate.

Steps:

  1. AI app: init MCP client with the MCP server address of Google Translate service;
  2. MCP client: get the capabilities of Google Translate MCP server via MCP server’s built-in list_tools API;
  3. AI app: build prompt, include all the function information of the Google Translate API (got from step 2) in the prompt;
  4. AI app: call LLM with the prompt;
  5. LLM: model response, with the selected function included;
  6. AI app: calling into the proper Google Translate API with MCP.

3.3 Comparison

  Function Call MCP
Prior knowledge of the AI app (configurations) Exact function names and parameters MCP server addresses
Functions the AI apps can use Static, only the pre-configured functions Dynamic, all functions the MCP server exposed via list_tools interface
Flexibility Low High
Token consumption Low High. When building a prompt, too many functions’ descriptions may be included into the prompt

Written by Human, Not by AI Written by Human, Not by AI