Model Context Protocol (MCP) Explained

Updated on Sep 28, 2026

9 min read

AI assistants are increasingly expected to do more than generate text: they may need to look up files, query services, or take an action with permission. The Model Context Protocol (MCP) is an open standard for connecting AI applications to those external systems through a shared interface. It is attracting attention because it addresses a recurring integration problem: connecting many AI hosts to many tools without building a separate adapter for every pair. The MCP project describes the protocol as a common way to connect AI applications to data and tools.

What Is Model Context Protocol?

MCP is a protocol that lets an AI application discover and use capabilities provided by another program. A server can offer tools that perform actions, resources that provide context, or prompts that supply reusable message templates. A compatible host can connect to that server and mediate how those capabilities are presented to an AI model.

The official MCP introduction compares MCP to a standard connector: rather than implementing a bespoke interface for each external system, an application and a service can implement the same protocol. The MCP specification defines the messages and behavior required for compatible implementations. MCP does not dictate which AI model to use, and it does not make a model inherently capable of safely acting on external systems.

The Problem MCP Solves

Before a common protocol, connecting an AI application to an external service often meant writing a custom integration. The application needed to understand that service’s API, authentication, response format, and error behavior. A second AI application could need a similar integration of its own. As the number of hosts and services grows, maintaining these pair-specific adapters becomes costly.

MCP establishes a reusable boundary. A service can expose capabilities through an MCP server, while each AI application can connect through an MCP client. An organization can then reuse a server across compatible hosts, subject to each host’s support and security policies. This reduces duplicated integration code, but it does not remove the work of building, operating, or securing the underlying service.

MCP also separates the tool contract from a model provider’s particular function-calling format. The host still translates the model’s tool-call request into MCP messages; MCP standardizes communication between the host and server, not the model’s internal behavior.

How MCP Works: Hosts, Clients, and Servers

An MCP connection has three roles:

Host: The AI application the person interacts with. It manages model conversations, user consent, and connections to MCP servers.
Client: A component inside the host that speaks MCP with a server. A host may create separate clients for separate server connections.
Server: A program that provides capabilities, such as reading selected project files or looking up records in a service.

In a typical tool interaction, the host connects to a server and discovers its available tools. It can describe suitable tools to the model using the model provider’s own interface. If the model proposes a call, the host applies its policies, sends a tools/call request through the MCP client, and returns the result to the model. The model does not open the network connection or execute the tool by itself; the host and server mediate the operation.

The protocol uses JSON-RPC 2.0 messages. Its JSON-RPC specification describes request and response objects, notifications, and error handling; MCP builds its own initialization, capability, and method rules on top. Implementations commonly use standard methods such as tools/list and tools/call, with separate methods for resources and prompts. A connection begins with initialization and capability negotiation so each side can establish which features it supports.

MCP defines local and remote transports. With stdio, a host launches a local server process and exchanges protocol messages over its standard input and output. With Streamable HTTP, a client communicates with a remote server over HTTP; the transport can support server-to-client updates as specified by MCP. HTTP’s general semantics are described in IETF RFC 9110, while MCP defines how protocol messages use its transport. Neither transport choice alone makes a server trustworthy.

Dimension	MCP server	Provider-specific tool calling	Direct API integration
Integration contract	Shared protocol methods and capability discovery	Tool schemas and behavior defined by a model provider	Application-specific code built around an API
Tool discovery	Client can request a server’s advertised tools	Application supplies tool definitions to the model	Application typically defines available operations itself
Reuse across hosts	A compatible server can serve multiple compatible hosts	Often requires adapting the provider’s tool format	Usually requires a separate integration for each application
Where execution happens	Host invokes the server and mediates the result	Application executes the provider-requested function	Application calls the external API directly
Transport options	Standard local stdio and remote HTTP transports	Determined by the provider API	Determined by the API and application design
Security responsibility	Host policy and server-side authorization both matter	Application and provider integration must enforce policy	Application must implement authorization and safeguards

These approaches can be combined. For example, an application can use a provider’s function-calling feature to let a model choose an action, then use an MCP client to invoke the corresponding server tool.

Core MCP Concepts

Tools are operations a model may ask the host to run, such as searching approved documents or creating a draft ticket. A tool has a name, description, and input schema. The host decides whether to expose it to the model, and the server validates its inputs and performs the operation.

Resources are data exposed by a server, such as a document or a record. They provide context but are not necessarily actions for the model to invoke. A host may let a person select a resource or retrieve it as part of its own context policy.

Prompts are reusable prompt templates that a server can provide to a host. A user or application may select one for a task. They are distinct from tools: a prompt shapes instructions, while a tool executes an operation.

The protocol also defines lifecycle behavior, capability negotiation, and notifications. These shared rules help clients handle different servers consistently, but they do not guarantee that every client implements every optional capability. Before building an integration, check the host and server support for the features and transport you plan to use.

Real-World Use Cases

MCP is useful when an AI application needs controlled access to multiple systems:

Developer assistants can use tools to search a codebase, read selected project context, or interact with a development service.
Enterprise assistants can connect to internal knowledge sources and business systems, with access limited by the user’s permissions.
Research workflows can retrieve material from approved data sources and use specialized tools for analysis.
Operational workflows can draft an issue or update a record after a person reviews the proposed action.

These examples describe possible system designs, not capabilities automatically granted by the protocol. A server still needs an implementation for each data source or action, and a host must decide which servers a user can access. Start with narrow, read-only tools where possible; add write operations only when their authorization, confirmation, and audit behavior are clear.

Getting Started: Build a Small MCP Server

The example below creates a local Python server with one harmless tool. It follows the official Python server tutorial, which requires Python 3.10 or newer and MCP Python SDK 2.0.0 or newer. Install uv first, then create a project and add the SDK:

uv init mcp-word-count
cd mcp-word-count
uv add "mcp[cli]"

Save this as server.py:

from mcp.server import MCPServer

mcp = MCPServer("word-count")


@mcp.tool()
def count_words(text: str) -> str:
    """Count whitespace-separated words in text."""
    return f"{len(text.split())} words"


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

The decorator exposes a typed tool, and the SDK derives its input schema from the function signature. The stdio transport is intended to be launched by an MCP host or test client, rather than used as a human-facing terminal prompt. Do not write diagnostic messages to standard output: it carries protocol messages, so extra text can break communication. Use a logger that writes to standard error instead.

To check that the server starts and advertises its tool, run the MCP Inspector CLI. The Inspector requires Node.js 22.19 or newer and launches the server command you provide:

npx @modelcontextprotocol/inspector --cli uv run server.py --method tools/list

Then invoke the tool and inspect its result:

npx @modelcontextprotocol/inspector --cli uv run server.py --method tools/call --tool-name count_words --tool-arg "text=three useful words" --format json

The first command should list count_words; the second should return 3 words. For a real integration, also test malformed inputs, server errors, authorization, and the behavior of the intended host. A passing local tool call verifies only this small path, not that a production deployment is secure or reliable.

Common Misconceptions

“MCP is an AI model.” It is a protocol for communication between AI applications and external services. A model may select a tool, but the host and server implement the connection and execution.

“Every MCP server can connect to every AI app.” Both sides must support compatible protocol features and transports. Hosts can also restrict which servers or tools are available.

“Standardized means safe.” A well-formed MCP server can still expose excessive access, accept unsafe input, or return malicious content. Treat tool output as untrusted, grant only necessary permissions, require human confirmation for consequential actions, and keep server-side authorization checks in place. Follow the project’s security best practices rather than relying on protocol compatibility as a security control.

Generative AI Models Explained covers the models that hosts can connect to tools and data.
Prompt Engineering for LLMs explains how instructions and context shape model behavior.
SmolLM2 and Smol-tools explores compact models and an agent that uses external tools.
API-First Development covers designing reusable interfaces for software integrations.

Changelog

Initial publication. Last updated: September 28.