MCP glossary

Last updated: June 2026

A reference of terms used across the Model Context Protocol ecosystem. Each definition reflects the MCP specification and current ecosystem usage as of the date above.

---

MCP (Model Context Protocol)

An open standard that defines how AI applications communicate with external tools and data sources through a structured JSON-RPC interface. MCP was introduced by Anthropic in November 2024 and is governed by the Agentic AI Foundation under the Linux Foundation. The protocol enables any MCP-compatible client to connect to any MCP-compatible server without custom integration code. See also: MCP disambiguation →

MCP server

A program that exposes one or more tools, resources, or prompts to MCP clients. An MCP server translates between the protocol’s JSON-RPC calls and the underlying system’s API. Examples: a GitHub MCP server exposes issues and pull requests; a Postgres MCP server exposes SQL queries and schema inspection. Servers are categorized as reference (maintained by the MCP project), vendor-maintained (built by the tool’s own company), or community (built by independent developers). Browse server profiles →

MCP client

An AI application that connects to MCP servers to access external tools and data. The client manages server connections, routes tool calls from the model, and returns results. Examples: Claude Desktop, Claude Code, Cursor, VS Code (via GitHub Copilot), Windsurf, ChatGPT. Each client supports a subset of MCP features and imposes its own limits on simultaneous connections and tool counts. Browse client profiles →

Host

The application that creates and manages MCP client instances. In most setups, the host and the client are the same application — Claude Desktop is both the host and the client. The distinction matters in embedded scenarios where one application hosts multiple client connections to different servers.

Tools

Actions that an MCP server exposes for the model to execute. A tool has a name, a description, and an input schema. Examples: create_issue (GitHub), run_query (Postgres), navigate (Playwright). When a client connects to a server, it discovers the server’s tools through the protocol and makes them available to the model. Each tool definition consumes context window tokens whether or not the tool is called.

Resources

Data that an MCP server exposes for the model to read. Unlike tools (which perform actions), resources provide information: a file’s contents, a database schema, a design token set, a document. Resources are identified by URIs. A server that exposes resources in addition to tools gives the model richer context for reasoning about the connected system.

Prompts

Reusable templates that an MCP server provides to structure common tasks. A prompt is a predefined instruction pattern the model can invoke — “summarize this PR,” “review this diff for security issues,” “explain this error.” Prompts reduce the need for users to craft task-specific instructions for each server interaction.

Sampling

A capability that allows an MCP server to request the client to generate text using the model. Sampling inverts the normal flow: instead of the client calling the server, the server asks the client’s model to produce a completion. This enables servers to implement multi-step reasoning or agentic loops where the server drives the interaction. Sampling requires explicit client support and user consent.

Roots

URIs that a client exposes to a server to define the boundaries of what the server should access. A root might be a project directory, a specific repository, or a database. Roots let the client tell the server “work within this scope” without exposing everything the client can access. The filesystem server, for example, uses roots to limit file access to specific directories.

Transport

The communication channel between an MCP client and server. The protocol supports multiple transports.

stdio (standard input/output)

A transport where the client launches the server as a local process and communicates through standard input and output streams. No network involved. The server runs on the same machine as the client. Stdio is the default transport for local MCP servers and the simplest to configure. Most servers in the ecosystem use stdio.

Streamable HTTP

The current standard transport for remote and hosted MCP servers, introduced in the 2025 specification updates. The client connects to the server over HTTPS, enabling servers to run on remote infrastructure, be shared across teams, and scale independently. Requires authentication (typically OAuth 2.1 or API key) and TLS. Replaces SSE as the recommended remote transport.

SSE (Server-Sent Events)

A legacy remote transport that uses HTTP Server-Sent Events for server-to-client streaming. SSE was the original remote transport in MCP. It is being deprecated in favor of streamable HTTP in the 2025 and 2026 specification updates. Some older servers and tutorials still reference SSE. Clients may drop SSE support as streamable HTTP adoption grows.

JSON-RPC

The message format MCP uses for communication between clients and servers. JSON-RPC is a lightweight remote procedure call protocol that uses JSON to encode requests, responses, and notifications. MCP uses JSON-RPC 2.0. Every tool call, resource read, and prompt invocation travels as a JSON-RPC message over the selected transport.

OAuth 2.1

The recommended authentication standard for MCP servers that require credentials. OAuth 2.1 tokens are scoped to specific permissions, time-limited, and revocable. MCP adopted OAuth 2.1 in the November 2025 specification update. Servers that support OAuth 2.1 are preferred over those requiring long-lived API keys pasted into configuration files in plain text.

Tool definitions

The JSON schema descriptions of a server’s tools that are loaded into the model’s context window when a server connects. Each tool definition includes the tool’s name, description, and input parameters. Tool definitions consume 500 to 2,000 tokens per server. Five connected servers can consume 7,500 tokens before the user types anything. This is the “tool definition tax” — the context window cost of having servers available.

Tool poisoning

An attack where a malicious MCP server embeds hidden instructions in its tool descriptions. When the model reads the tool definitions during discovery, it follows the hidden instructions — which might include exfiltrating environment variables, reading credentials, or executing unintended actions. The user sees the tool name in the interface but not the hidden instructions in the description. Defense: install servers from trusted sources and review tool descriptions in MCP Inspector before connecting unfamiliar servers.

Elicitation

A capability that allows an MCP server to request additional information from the user during a tool call. Instead of failing when required input is missing, the server can ask the user to provide it. Elicitation enables more interactive server workflows but requires explicit client support.

Context window

The total amount of text (measured in tokens) that a language model can process in a single interaction. Tool definitions, conversation history, tool call responses, and the model’s own output all compete for space in the context window. A 200,000-token window absorbs tool definitions easily. A 32,000-token window loses significant capacity to tool definitions alone if many servers are connected.

Reference server

An MCP server maintained by the MCP project under the Linux Foundation. Seven reference servers are active as of mid-2026: Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, and Time. Thirteen former Anthropic reference servers (including GitHub, Postgres, Slack, and Puppeteer) were archived and replaced by vendor-maintained versions.

Vendor-maintained server

An MCP server built and maintained by the company that owns the underlying tool. GitHub maintains the GitHub MCP server. Stripe maintains the Stripe MCP server. Figma, Supabase, Linear, Slack, and at least 50 other vendors maintain their own. Vendor-maintained servers are generally more reliable and better maintained than community alternatives because the vendor has a commercial interest in the server working correctly.

Community server

An MCP server built by an independent developer, not by the tool’s vendor or the MCP project. Quality ranges from production-grade to abandoned. The quality signal is commit recency, not star count. Community servers fill gaps where no vendor or reference server exists.

MCP Registry

A directory that lists published MCP servers with metadata. The official MCP Registry (registry.modelcontextprotocol.io) lists over 9,600 server records as of mid-2026. Other registries include PulseMCP (15,900+), Smithery (7,300+), and mcp.so. No single registry indexes all servers. Registries list servers but do not verify maintenance status or specification compliance.

MCP Inspector

A debugging tool for MCP servers that shows the raw tool descriptions, resource URIs, and prompt templates exactly as the model will read them. Used to verify server behavior, debug connection issues, and audit tool descriptions for hidden instructions (tool poisoning). Essential for vetting unfamiliar servers before connecting them to a client with real credentials.

Configuration file

The JSON file where MCP clients store server connection details — command, arguments, environment variables, and API tokens. In Claude Desktop, this is claude_desktop_config.json. In Cursor, it is .cursor/mcp.json. Credentials in the config file are stored in plain text. Protect this file accordingly.