AI glossary

Model Context Protocol (MCP)

The Model Context Protocol (MCP) is an open standard that defines how AI applications, such as assistants, coding tools and agents built on large language models, connect to external tools, data sources and systems through one common interface.

For years, integrating an AI app with a new data source meant writing custom code for every single combination. If you had ten apps and ten tools, you needed a hundred connections. MCP changes that math. By standardizing the interface, a single MCP server can now serve any compatible application, much like how USB-C replaced a drawer full of different chargers.

What problem MCP solves

Without a standard, every AI application needs a custom integration for every tool or data source. The number of integrations grows as the number of applications multiplied by the number of tools. With MCP, a tool or data source is exposed once as an MCP server, and any MCP-compatible application can use it.

This approach is often compared to USB-C: one connector for many devices. Instead of building unique bridges for every new data source, developers build one bridge that any MCP host can cross. This reduces engineering overhead and makes it easier to swap out data sources or tools without rewriting the core application logic.

How MCP works: hosts, clients and servers

The architecture of MCP relies on three distinct components that work together to facilitate communication between the AI and external systems.

The host is the AI application the user interacts with directly. Examples include a desktop assistant, a code editor or a conversational AI interface. The host orchestrates the user experience and manages the overall workflow.

Inside the host sits the client. This component maintains a one-to-one connection with a single MCP server. A host can run several clients simultaneously, allowing it to connect to multiple data sources or tools at once. The client handles the protocol details, such as sending requests and parsing responses.

The server is a program that exposes capabilities to clients. It might provide access to a database, a file system, a ticketing system, or a web API. The server defines what tools, resources, and prompts are available and handles the execution logic when the model decides to use them.

Tools, resources and prompts

MCP servers expose specific primitives that allow the large language model to interact with external systems meaningfully. These are not just raw data dumps; they are structured interactions designed for AI consumption.

Tools are functions the model can call. Examples include running a database query or creating a support ticket. Each tool has a name, a description, and an input schema defined with JSON Schema. The client can list these tools at runtime, allowing the model to understand exactly what actions are available and how to invoke them.

Resources are data the application can read and provide as context. This includes files, database records, or real-time feeds. By exposing resources, servers allow the AI to ground its responses in specific, up-to-date information rather than relying solely on its training data.

Prompts are reusable prompt templates and workflows offered by the server. Instead of constructing a complex prompt from scratch every time, the application can request a pre-defined prompt structure from the server, which keeps common workflows consistent.

Clients can also offer features to servers. For example, sampling lets a server ask the client’s model to generate text. This lets a server use a language model through the client instead of calling a model directly.

Transports and message format

MCP is transport-agnostic but relies on a strict message format. All messages use JSON-RPC 2.0, ensuring that data exchange is structured and predictable regardless of the underlying connection method.

There are two primary transport modes:

  1. stdio transport: This is used for local servers that the host starts as a subprocess. It is ideal for development and local tools where low latency and direct process communication are required.
  2. Streamable HTTP transport: This is used for remote servers. It was introduced in the 2025-03-26 revision of the specification and replaced the earlier HTTP with Server-Sent Events transport. This mode allows servers to be accessed over a network, enabling cloud-based tools and data sources.

For remote servers, authorization is based on OAuth 2.1, providing a secure way to manage access tokens and permissions. Official SDKs exist in several languages, including Python and TypeScript, which simplify the implementation of both clients and servers.

A minimal MCP server in Python

To understand how easy it is to create an MCP server, consider this minimal example using the official Python SDK. The code defines a server named “weather” with a single tool.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

@mcp.tool()
def get_forecast(city: str) -> str:
    """Return a short weather forecast for a city."""
    return f"Forecast for {city}: sunny, 22°C"

if __name__ == "__main__":
    mcp.run()  # stdio transport by default

The function name, docstring, and type hints automatically become the tool’s name, description, and input schema. The client discovers this tool at runtime and can invoke get_forecast with a city name. Note that the forecast value in the example is a hard-coded placeholder, not a real weather lookup, but the structure is ready for real data integration.

MCP vs APIs and function calling

It is important to clarify what MCP is not. MCP does not replace APIs. In fact, MCP servers usually wrap existing APIs. What MCP adds is a standard way for AI applications to discover available tools and data at runtime and call them, with descriptions written specifically for the model.

Similarly, MCP is distinct from function calling. Function calling is a capability of a model inside one provider’s API: the model decides to call a function you described. MCP standardizes how tools are packaged, discovered, and served across applications. A host still relies on the model’s function calling to decide which MCP tool to invoke. MCP provides the infrastructure for the tool; the model provides the decision-making.

Security considerations

Because an MCP server runs code with access to data and systems, security is a primary concern. Developers should install only servers from sources they trust and carefully review what permissions they grant.

Tool descriptions and tool outputs are text the model reads. This means they can carry prompt injection attacks. A malicious server can hide instructions in a tool description, a vulnerability often called tool poisoning. To mitigate this, apply least privilege principles, scope access tokens narrowly, and require user approval for sensitive tool calls. Always treat tool outputs as untrusted text that the model might misinterpret.

Adoption

OpenAI announced MCP support in March 2025, starting with its Agents SDK. Google and Microsoft also announced support for MCP in their products during 2025.

FAQ

What is MCP in AI?

MCP stands for Model Context Protocol. It is an open standard that allows AI applications to connect to external tools and data sources through a unified interface, reducing the need for custom integrations.

How does MCP differ from a standard API?

A standard API is a technical interface for software-to-software communication. MCP wraps APIs in a way that allows AI models to discover, understand, and invoke tools dynamically at runtime using natural language descriptions.

What is an MCP server?

An MCP server is a program that exposes tools, resources and prompts to AI applications over MCP. It often wraps an existing API, database or file system so that any MCP-compatible application can use it.

Do I need to rewrite my existing APIs to use MCP?

No. MCP servers typically wrap existing APIs. You create a server that exposes your API’s functionality through MCP primitives like tools and resources, allowing existing AI apps to use your data without changing the underlying API.