1. What Is MCP?

In the AI agents guide, we covered how agents use tools to interact with the world. An agent reads a database, calls an API, searches the web, or executes code. Each of these actions requires a connection between the model and an external system. Building those connections has historically been ad hoc. Every agent framework, model provider, and tool integration used its own format, its own authentication, and its own way of describing what the tool does.

The Model Context Protocol, or MCP, is an open standard that solves this fragmentation. It defines a common protocol for communication between AI applications and external data sources and tools. An easier way to think of it is as USB-C for AI integrations. Before USB-C, every device had its own connector, however, after USB-C, one cable can now work with everything. MCP aims to do the same for the connection between models and tools.

MCP was introduced by Anthropic in late 2024 and has since gained adoption across model providers, agent frameworks, and tool developers. The protocol is open source, meaning anyone can implement it without licensing restrictions, and it is designed to be model-agnostic, meaning it works with any LLM.

2. Why MCP Exists

Before MCP, connecting an AI model to an external tool required custom integration work. If you wanted your agent to read from a database, you wrote code that connected the model to the database, defined the tool's schema, and handled the communication format. If you then wanted the same agent to also read from a file system, you wrote another integration. If you switched model providers, you rewrote both integrations because the new provider used a different tool-calling format.

This N-by-M problem, where N models each need to support M tools, creates a combinatorial explosion of integrations. With 10 models and 100 tools, you need 1,000 separate integrations. MCP reduces this to N plus M. Each model implements the MCP client protocol once. Each tool implements the MCP server protocol once. Any model can then use any tool.

The practical benefit is reuse. A developer who builds an MCP server for a database makes that database accessible to every MCP-compatible AI application. A team that builds an MCP client in their agent gets access to every MCP server that exists, without writing additional integrations.

3. How MCP Works

MCP follows a client-server architecture. The MCP client runs inside the AI application, and the MCP server wraps the external tool or data source. The client and server communicate using a standard protocol based on JSON-RPC, a lightweight message format that sends structured requests and responses.

4. MCP Components

Understanding MCP means understanding the three types of capabilities a server can expose and how the client uses them.

The distinction between tools and resources matters. Tools are active, meaning the model calls them to perform an action or retrieve data. Resources are passive, meaning they are available context that the model can read. A database query tool lets the model run arbitrary SQL. A database resource presents a specific record to the model without requiring a tool call. The choice between exposing something as a tool or a resource depends on whether the model needs to actively request it or whether it should be available as context.

5. Building an MCP Server

Building an MCP server means wrapping an external system and exposing it through the protocol. The process involves defining the tools and resources the server offers, implementing the logic for each, and running the server on a transport.

Several SDKs are available for building MCP servers, including Python and TypeScript. The SDKs handle the protocol details, like message formatting and capability advertisement, so you can focus on the tool logic. A typical server defines its tools as functions, each with a name, description, and parameter schema. When a client sends a tool call request, the server executes the corresponding function and returns the result.

6. MCP and Agents

MCP and agents are complementary. As covered in the AI agents guide, an agent uses a model to plan and execute multi-step workflows, calling tools along the way. MCP provides the standardised interface through which those tool calls happen.

Without MCP, an agent framework needs custom integrations for every tool it supports. The framework defines its own tool-calling format, and developers write adapters to connect external systems. With MCP, the framework only needs to implement the MCP client protocol. Every MCP server becomes available as a tool source, and the framework does not need to know the details of how each tool works.

This separation of concerns is valuable. Agent developers can focus on planning, reasoning, and orchestration without reimplementing tool integrations for each new data source. Tool developers can build MCP servers without knowing which agent frameworks will use them. The protocol acts as a clean boundary between the two layers.

7. MCP vs Function Calling

Function calling is a capability built into modern language models. The model is given a list of functions with their parameter schemas, and it can decide to call a function by producing a structured output with the function name and arguments. The application executes the function and returns the result to the model.

MCP and function calling serve different layers of the stack. Function calling is a model capability, meaning the model can produce structured tool-call requests. MCP is a protocol, meaning it defines how those requests are routed to external systems and how results are returned. The two work together. The model uses function calling to decide which tool to call and with what parameters. MCP transports that request to the appropriate server, executes it, and returns the result.

In practice, an MCP-compatible application uses function calling internally. The model produces a tool-call request using its native function-calling format. The application translates this into an MCP request and sends it to the server. The distinction is that MCP standardises the layer between the model and the tool, so the application does not need custom code for each tool.

8. Security and Trust

MCP servers give AI models access to external systems, which means they also introduce security considerations. A model that can query a database can potentially access sensitive data. A model that can send messages can potentially send unauthorised communications. A model that can execute code can potentially run harmful commands.

Several security practices are important when deploying MCP. Least privilege means each server should expose only the tools and resources the model needs, with the minimum permissions required. A database server for a read-only Q and A system should not expose write or delete tools. Authentication means the server should verify the identity of the client and enforce access controls. Input validation means the server should validate all parameters before executing a tool, rejecting requests that contain invalid or potentially harmful input.

User consent is another consideration. For actions that have real-world consequences, like sending an email or modifying a database record, the application should ask the user for confirmation before the server executes the tool. This is human-in-the-loop, as covered in the AI agents guide. MCP itself does not enforce these practices. It is a protocol, not a security framework. The responsibility for secure deployment falls on the developers building and configuring the servers.

9. The MCP Ecosystem

Since its introduction, MCP has grown a substantial ecosystem of servers, clients, and tools. Several categories have emerged.

10. The Future of MCP

MCP is still early in its adoption curve. The protocol defines the basic mechanics of tool discovery, invocation, and result return, but several areas are evolving.

Remote deployment is one direction. Currently, many MCP servers run locally through stdio transport, which limits them to single-user, single-machine setups. Remote MCP servers running over HTTP would enable shared tool access across teams and organisations. This raises additional security considerations, including authentication, encryption, and access control, which the protocol is beginning to address.

Standardisation across model providers is another direction. While MCP is model-agnostic, the way models use MCP-exposed tools still depends on their native function-calling format. Further standardisation of the tool-calling layer would reduce the remaining differences between model providers.

The broader question is whether MCP becomes the universal standard for AI-tool integration, or whether competing protocols fragment the ecosystem. The open source nature of MCP, combined with growing adoption from both model providers and tool developers, gives it a strong position. But standards succeed when they reach critical mass, and MCP is still building toward that point.

Frequently Asked Questions