Model Context Protocol (MCP): what it is and how it works

The Model Context Protocol (MCP) is an open protocol that connects AI applications — the 'clients' — to external servers that expose tools, resources, and prompts. A host application (such as a coding agent or desktop assistant) delegates to a client, which communicates with one or more servers over a JSON-RPC transport. Servers run locally over stdio or remotely over HTTP. MCP standardizes what used to be a tangle of one-off integrations.

Before MCP, connecting an AI assistant to a database, a search engine, or a file system meant writing a bespoke integration for every data source and every assistant. Each pair had to agree on request shape, authentication, and error handling. MCP defines one protocol so that a single server can be consumed by any compatible client, and a single client can drive any server that follows the protocol.

MCP is built on the JSON-RPC 2.0 message format. At startup, the client sends an initialize request carrying a protocol version and a list of capabilities. The server replies with its own version and capabilities. The two sides then exchange notifications. Once connected, the client can list tools, call tools, read resources, and list prompts.

The MCP specification distinguishes three roles. A host is the surrounding application that holds a user or agent context and provides the UI or the model. A client is the protocol participant that maintains a one-to-one connection to a server and translates host intent into protocol requests. A server exposes the protocol primitives — tools, resources, prompts — for a specific capability.

Servers expose three kinds of primitives. Tools are callable functions defined by an input schema and invoked via tools/call. Resources are addressable data returned through a read request with an optional MIME type. Prompts are reusable invocation templates the client can present to the user. Each primitive has its own list-and-request lifecycle.

A server may run on the same machine as the client and communicate over stdio, or on a remote host and communicate over HTTP. Local servers are simple to start and require no network. Remote servers are addressable over the network and involve authentication. The protocol supports both; which one applies depends on the server implementation.