MCP glossary

Model Context Protocol (MCP)

The Model Context Protocol is an open standard that lets an AI application discover and call tools on an external server over a shared JSON-RPC interface. The client opens a connection, agrees a protocol revision with the server, asks what the server can do, and calls what comes back. Anthropic published it in November 2024.

MCP server

An MCP server is a program that exposes tools, resources, or prompts to AI applications over the Model Context Protocol. It answers an initialize request with a protocol revision, then answers tools/list with the capabilities it offers. It can run as a local process or as a URL on the public internet.

MCP client

An MCP client is the side of a Model Context Protocol connection that consumes capabilities. It opens the transport, sends the initialize request, reads the server's tool list, and decides which of those tools to expose to a model. Claude Desktop, IDE extensions, and custom agents are all MCP clients.

JSON-RPC 2.0

JSON-RPC 2.0 is the message format every Model Context Protocol exchange uses. Each message is a JSON object carrying a jsonrpc version string, a method name, and either an id for requests or no id for notifications. MCP defines the method names; JSON-RPC defines the envelope they travel in.

initialize

initialize is the first request in an MCP connection. The client sends the protocol revision it wants plus its own name and version; the server replies with the revision it will actually use, its own identity, and its capabilities. Nothing else can be called until this exchange completes.

capabilities

Capabilities are the feature sets a client and server declare during initialize. Each side announces what it supports, such as tools, resources, prompts, or logging, and neither is expected to use anything the other did not declare. It is a negotiation, not a fixed list every implementation has to satisfy.

protocol revision

A protocol revision is the dated version of the MCP specification a connection runs on, written as a date such as 2025-11-25. The client proposes one during initialize and the server answers with the one it will actually use. MCP versions by date rather than by semantic version number.

tool

A tool is a single callable function an MCP server exposes to a client. Each one is described by a name, a JSON Schema for its arguments, and usually a description written for a model rather than a human reader. Tools are the most used MCP capability and the unit a client hands to a model.

tools/list

tools/list is the JSON-RPC method an MCP client calls to discover what a server can do. It returns an array of tool objects and an optional nextCursor for pagination. It is the first call after the handshake and the one that decides whether a server is usable at all.

inputSchema

inputSchema is the JSON Schema object describing a tool's arguments. It tells the client what parameters exist, their types, and which are required, so a model can construct a valid call without a human writing an integration. It is required on every tool and was present on all 288 tools we read.

outputSchema

outputSchema is an optional JSON Schema describing the structured result a tool returns. It lets a client validate and parse a response instead of treating it as opaque text. It is genuinely optional, and only 5.6% of the 288 tools we read on 5 August 2026 carried one.

tool annotations

Tool annotations are optional hints on a tool object describing how it behaves: whether it only reads, whether repeating it is safe, whether its effects are destructive, and whether it touches the open world. The specification requires clients to treat them as untrusted unless the server is trusted.

nextCursor

nextCursor is an opaque pagination token an MCP server may include in a tools/list response. Its presence means more tools exist and the client must call again with that cursor to get them. A client that ignores it sees a truncated list and receives no error explaining why.

Streamable HTTP

Streamable HTTP is the MCP transport where a client POSTs JSON-RPC messages to a single URL and the server answers with either a JSON response or an SSE stream. It replaced the older two-endpoint HTTP+SSE transport and is what makes a remote MCP server reachable at one address.

stdio

stdio is the MCP transport where a client launches the server as a child process and exchanges JSON-RPC messages over its standard input and output. There is no URL and no network hop. It is the default for local, single-user servers and the most common transport in the ecosystem.

Server-Sent Events (SSE)

Server-Sent Events is a one-way streaming format where a server pushes text events over a held-open HTTP response. MCP uses it inside the Streamable HTTP transport when a server needs to send several messages for one request. The older standalone HTTP+SSE transport it also named has been deprecated.

Mcp-Session-Id

Mcp-Session-Id is an HTTP header a Streamable HTTP server may return during initialize to identify a session. A client that receives one must echo it on every subsequent request. It lets a stateful server correlate calls across separate HTTP requests, and the 2026-07-28 revision removes it.

MCP authorization

MCP authorization is how a Streamable HTTP server decides whether a caller may connect. The specification requires internet-facing servers to use OAuth 2.1, and servers commonly answer an unauthenticated request with HTTP 401 plus metadata pointing at their authorization server. Local stdio servers have no such requirement.

auth_required

auth_required is the outcome we record when an MCP endpoint answers a connection attempt with HTTP 401 or 403. It means the address answered, was serving, and was guarding itself at the moment we asked. It is the most common result we have recorded, and it describes a working server rather than a broken one.

connection test

A connection test is a live handshake against an MCP endpoint that records what came back: whether it connected, the protocol revision it negotiated, the tools it listed, and one round trip in milliseconds. It is a dated observation of one address at one moment, not a statement about the server's present state.