Model Context Protocol (MCP)

How the Model Context Protocol works

MCP gives AI applications one way to reach outside systems. Without a shared protocol, each pairing of an AI application and a data source needs its own connector. With MCP, a team builds one server, and any application that speaks the protocol can use it. The specification names the Language Server Protocol, which did the same for programming languages across development tools, as an inspiration 1.

The protocol has three roles. A host is the AI application that starts connections, a client is a connector inside the host, and a server provides context and capabilities 1. The host creates one client for each server it connects to, and each client keeps a dedicated connection to its server 2.

Two layers sit under those roles. The data layer is the JSON-RPC 2.0 protocol itself, covering discovery, server features, client features and utilities such as notifications and progress tracking 2. The transport layer moves the messages and handles connection setup, framing and authorization 2. A server on the stdio transport runs on the same machine as the client, and a server on Streamable HTTP runs as a remote service 2. For remote servers, MCP recommends OAuth to obtain authentication tokens 2.

The current revision makes each request self-contained 1. Every request carries the protocol version and the client's capabilities in its metadata, and a client that wants to learn what a server supports sends a server/discover request first 2. The server answers with its supported versions and capabilities 2. The client then lists the server's MCP tools, and the model calls them through tool calling. The service on the far side is an MCP server, and the connector inside the application is an MCP client.

What MCP servers and clients offer

The specification defines a short list of features on each side of the connection.

• Tools are functions for the AI model to execute 1. A tool might run a search, look up a record or write to another system.
• Resources are context and data for the user or the model, such as file contents, database records or API responses 2.
• Prompts are templated messages and workflows for users 1.
• Elicitation lets a server ask the user for more information through the client 1.

The current revision also defines opt-in extensions that both sides must support, including Tasks for long-running operations and MCP Apps for interactive elements shown inside a conversation 1. Sampling, a client feature in earlier revisions, is deprecated as of this one 2.

Consent sits with the host. Hosts must obtain explicit user consent before they invoke any tool, and before they expose user data to a server 1. The specification also tells implementers to treat tool descriptions as untrusted unless they come from a trusted server 1. For a data API, tools are where the work happens, because each useful action is a call that fetches, checks or writes data. A remote MCP server is a common shape for that kind of service.

Example of the Model Context Protocol

The official MCP architecture guide walks through a tool exchange 2. After discovery, the client sends a tools/list request, and the server returns each tool with a name, a title, a description and an inputSchema 2. One tool in the guide's example looks like this, shortened here 2.

{"name": "weather_current", "title": "Weather Information",
 "description": "Get current weather information for any location worldwide",
 "inputSchema": {"type": "object",
  "properties": {"location": {"type": "string"},
   "units": {"type": "string", "enum": ["metric", "imperial", "kelvin"]}},
  "required": ["location"]}}

The description tells the model when the tool fits a request, and the inputSchema tells the client which arguments are required 2. The client then sends tools/call with the tool name and its arguments, and the server returns a result for the model to read 2. The list response in the guide also carries a ttlMs value of 300000, a hint that the tool list can be cached for five minutes 2.

A data provider uses the same exchange. RichAPI runs a remote MCP server at mcp.richapi.ai 4. A user pastes the server URL into an MCP client, signs in when the client opens RichAPI, and clicks Allow. There is no API key to copy 4. That sign-in is the authorization step on the HTTP transport. From then on, a request such as verifying a list of emails becomes a tool call, and the RichAPI page states that email verification through the server costs 2 credits per email 4.

Model Context Protocol vs REST API

Both let software reach a service, and an MCP server often wraps an existing API. A REST API is an interface any program can call, documented for a developer who writes the calling code. MCP adds a layer an AI application can use without custom code, because the client discovers the tools, reads their descriptions and schemas, and lets the model decide when to call them 2. The trade is control. Code that calls a REST endpoint does exactly what the developer wrote. In an MCP session the model chooses the tool and the arguments, and the host must get user consent before any tool runs 1.