What is the Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external tools, data and workflows. An AI app such as Claude, ChatGPT, Cursor or VS Code connects to MCP servers, each of which exposes one system’s functions in a common format (MCP introduction). The messages are JSON-RPC 2.0 (specification). Anthropic introduced it in November 2024 (announcement), and as of 30 October 2026 the current spec revision is 2026-07-28 (versioning).

How MCP works

The architecture has three roles. The host is the AI application the user works in. Inside it, each client holds a connection to one server. The server wraps a system such as a database, a ticket tracker or a file system.

A server offers three kinds of features (server overview):

Feature	What it is	Example
Tools	Functions the model can call	API POST requests, file writing
Resources	Contextual data the client attaches and manages (application-controlled)	File contents, git history
Prompts	Templated messages and workflows a user picks	Slash commands, menu options

A tool is described by a name, a description and a JSON Schema for its arguments. The client sends tools/list to discover tools and tools/call to run one (tools spec). The spec calls tools model-controlled: the model can discover and invoke them based on its understanding of the context and the user’s prompts.

Messages travel over one of two standard transports (transports):

• stdio carries newline-delimited messages over the standard streams of a subprocess the client launches.
• Streamable HTTP sends each message as an HTTP POST to a single endpoint, and replies arrive as a JSON object or a request-scoped SSE stream.

Message meaning is identical on both, so the same server can run as a local process or as a hosted endpoint.

A tool call and its result look like this, quoted from the tools spec (its examples omit the required request _meta for brevity):

{"jsonrpc": "2.0", "id": 2, "method": "tools/call",
 "params": {"name": "get_weather", "arguments": {"location": "New York"}}}

{"jsonrpc": "2.0", "id": 2, "result": {"resultType": "complete",
 "content": [{"type": "text", "text": "Current weather in New York:\nTemperature: 72°F\nConditions: Partly cloudy"}],
 "isError": false}}

What changed in the 2026-07-28 revision

The version string is the date of the last backwards incompatible change (versioning). The changelog lists these changes since 2025-11-25 (read 2026-10-30):

Area	Change
Sessions	Mcp-Session-Id and protocol-level sessions removed. Servers that need state across calls mint their own handle and take it back as a tool argument.
Handshake	initialize removed. Every request carries its protocol version and client capabilities in _meta.
Discovery	New required server/discover method returns supported versions, capabilities and server identity.
Notifications	subscriptions/listen replaces the HTTP GET stream and resources/subscribe. SSE resumability (Last-Event-ID) is removed, so a broken stream means re-issuing the request.
Server questions	Multi round-trip requests replace server-initiated requests. Every result now has a resultType.
Tasks	Moved out of core into the official io.modelcontextprotocol/tasks extension, now polled with tasks/get.
Caching	tools/list and other list results require ttlMs and cacheScope. Servers SHOULD return tools in a stable order.
Tracing	Conventions for OpenTelemetry traceparent, tracestate and baggage in _meta.
Auth	Clients MUST validate iss when present (RFC 9207). Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents.
Deprecated	Roots, Sampling and Logging, plus the old HTTP+SSE transport. Deprecated features normally stay at least twelve months before removal, or at least ninety days under the expedited-removal exception (versioning).

MCP server, function tool or direct API call?

MCP is one way to give a model a capability. This table is a rule of thumb, not part of the spec.

Situation	Choose	Why
One app, one model provider, a tool only that app needs	Function tool in your agent code	No extra process to run or secure
The same integration must work in several hosts (IDE, chat app, your own agent)	MCP server	Written once, usable by any client that speaks MCP
You ship a product and want any AI client to use it	Hosted MCP server over Streamable HTTP	Clients connect to one URL, nothing to install locally
A local tool that touches the user’s files or shell	stdio MCP server	The spec advises stdio to limit access to the client (security best practices)
A fixed step the model never needs to choose	Direct API call in your code	Deterministic, with nothing for the model to choose or get wrong

The trade is reuse against operating cost: an MCP server is another component to authenticate, rate limit, version and debug.

Security notes from the spec

The tools spec says there SHOULD always be a human in the loop who can deny tool invocations, and that clients MUST treat tool annotations as untrusted unless they come from a trusted server. It also sets baseline duties:

• Servers MUST validate all tool inputs, apply access controls, rate limit calls and sanitize outputs.
• Clients SHOULD show tool inputs to the user before the call, validate results before passing them to the model, set timeouts and log tool usage for audit.

Runtime checks on tool inputs and outputs are covered in AI guardrails. The security best practices page covers the main attacks:

Risk	Requirement
Confused deputy (MCP proxy with a static client ID)	Proxies MUST get per-client user consent before forwarding to the third-party authorization server
Token passthrough	Servers MUST NOT accept tokens not explicitly issued for the MCP server
State handle hijacking	Servers MUST NOT treat possession of a handle as authentication, and SHOULD bind handles to the verified user
SSRF during OAuth discovery	Clients SHOULD require HTTPS and block private and link-local IP ranges
Local server compromise	Clients MUST show the exact command and get approval before one-click local server setup
Scope creep	Start with minimal scopes and step up through targeted challenges

Tracing MCP tool calls in HoneyHive

HoneyHive’s MCP tracing guide covers Python servers and clients. It offers experimental OpenInference auto-instrumentation and, recommended for production, @trace decorators with enrich_span to record tool name, arguments, result status and timing. As of 30 October 2026 the guide lists mcp >= 1.0.0 and Python 3.11 to 3.13. To have a coding agent do the setup, install the honeyhive-instrument skill with npx skills add honeyhiveai/skills --skill honeyhive-instrument (AI coding agents). For how tool calls show up inside a whole agent run, see agent observability, and for the wider practice LLM observability.

FAQ

How is MCP different from an API?

An API is the interface of one service, written for developers who code against its docs. MCP is a shared format many services can wrap their APIs in, so an AI app can list a server's tools at runtime with tools/list and call them with tools/call without service-specific code.

What is MCP vs RAG?

RAG (retrieval-augmented generation) is a technique: retrieve relevant text and add it to the prompt. MCP is a protocol for connecting a model to outside systems, covering retrieval but also actions such as creating a ticket. A retrieval step can be exposed as a tool or resource on an MCP server.

Is MCP the same as HTTP?

No. MCP defines JSON-RPC 2.0 messages and their meaning. HTTP is one way to carry them (Streamable HTTP). The other standard transport, stdio, uses a local subprocess's input and output with no HTTP.