MCP glossary: every term explained

Anyone digging into the Model Context Protocol quickly runs into a string of technical terms: from Streamable HTTP to tool poisoning. This glossary explains 32 core terms in one paragraph each — ordered alphabetically, so you can quickly look up what you need. Every definition stands on its own and can be quoted as-is in a proposal, policy document or internal presentation. New to MCP? Start with What is MCP? and How does MCP work?, and keep this list at hand as a reference.

A2A (Agent2Agent Protocol)

A2A is an open protocol for communication between AI agents, created by Google (April 2025) and donated to the Linux Foundation in June 2025. A2A does not compete with MCP but complements it: MCP handles the traffic between an agent and its tools or data, A2A handles the traffic between agents themselves. According to the Linux Foundation, more than 150 organisations now support A2A.

Agentic AI

Agentic AI is the umbrella term for AI systems that autonomously carry out multi-step tasks: they plan, call tools, process the results and decide on next steps — rather than merely generating text. For agentic AI, MCP has become the standard layer through which agents get secure access to systems, data sources and applications, without every integration having to be built separately.

Agentic AI Foundation (AAIF)

The Agentic AI Foundation is a fund under the Linux Foundation that has held the ownership and governance of MCP since 9 December 2025. The AAIF was founded by Anthropic, Block and OpenAI, with support from Google, Microsoft and AWS among others, and started with three projects: MCP, goose and AGENTS.md. Thanks to this donation, MCP is vendor-neutral infrastructure — not a protocol owned by a single supplier.

Deprecation policy

The deprecation policy is MCP's formal phase-out process, introduced with spec version 2026-07-28. Features move through three stages — Active, Deprecated, Removed — with at least twelve months between deprecation and removal. That gives organisations a guaranteed migration window. The first features entering this pipeline are sampling, roots and logging, each with a documented alternative.

Elicitation

Elicitation is the MCP mechanism through which a server requests additional input from the user during an ongoing operation, for example via a schema-based form. It was introduced in spec version 2025-06-18 and extended in 2025-11-25 with default values, richer option lists and URL mode: the server can direct the user to an external page, such as a payment or login flow.

FastMCP

FastMCP is the most popular Python framework for building MCP servers: type hints and docstrings are automatically converted into tool schemas, so a working server takes about ten lines of code. Mind the distinction: FastMCP 1.0 was folded into the official Python SDK in 2024, while the standalone fastmcp package (version 3.x) continues to evolve with auth providers and OpenAPI generation. See build your own MCP server.

Human-in-the-loop

Human-in-the-loop is the design principle that a human explicitly approves critical AI actions before they are executed. Within MCP this is built in at host level: according to the official documentation, tool calls happen with the user's consent, and the host enforces the security and consent policy. For businesses, this is the most important brake on unwanted autonomous agent actions.

JSON-RPC

JSON-RPC is the message format MCP is built on: all communication between client and server consists of JSON-RPC 2.0 messages in UTF-8. JSON-RPC defines what requests, responses and notifications look like; MCP adds the content, such as tools/list and tools/call. Because the format is transport-independent, the same message works over stdio and over Streamable HTTP.

llms.txt

llms.txt is a web convention in which a website publishes a compact markdown file at a fixed location, giving language models a summary and reading guide for the site. It is separate from the MCP protocol itself, but often comes up in the same discussions: both make content and functionality more usable for AI systems — llms.txt passively (readable context), MCP actively (executable tools).

MCP (Model Context Protocol)

MCP is an open, JSON-RPC-based protocol that standardises how AI applications connect to external tools, data sources and services — often summed up as "the USB-C port for AI". It solves the N×M integration problem: one MCP server works with every MCP-compatible client. Anthropic launched MCP on 25 November 2024; since December 2025 it has been governed by the Agentic AI Foundation. Read more at What is MCP?

MCP client

An MCP client is the protocol connector inside a host application that maintains the connection to exactly one MCP server — the spec mandates a strict 1-to-1 relationship. The client handles capability negotiation, routes messages and guards the security boundary between servers. If you use five servers in Claude Desktop, five clients are running, each isolated from the others.

MCP host

The MCP host is the AI application itself, such as Claude Desktop, VS Code or ChatGPT. The host creates and manages the clients, enforces security policy and user consent, and coordinates the integration with the language model. Crucial for privacy: the full conversation history stays with the host — servers only receive the context needed for their task and never see the whole conversation.

MCP Inspector

The MCP Inspector is the official visual testing and debugging tool for MCP servers, launched directly with npx @modelcontextprotocol/inspector. In the web interface you can call tools with arbitrary arguments, browse resources and prompts, and follow the raw JSON-RPC messages. According to the official documentation, it is the standard first debugging step before connecting a server to a real client.

MCP server

An MCP server is a program — local or remote — that offers specific capabilities to AI applications via the protocol: tools, resources and prompts. Servers operate independently, receive only the necessary context and cannot look into other servers or the full conversation. The spec is deliberately designed so that servers are extremely simple to build. Browse examples by sector in our server directory.

Namespace

A namespace is the verified naming space under which an MCP server is published in the official registry, in reverse-DNS notation: io.github.username/server (via GitHub login) or com.company/server (via DNS or HTTP verification). Only the verified owner can publish under a namespace. That makes the publisher verifiable — although a valid namespace says nothing about the quality or security of the server itself.

OAuth 2.1

OAuth 2.1 is the authorisation standard MCP mandates for remote servers. The MCP server acts as an OAuth resource server and publishes, via Protected Resource Metadata (RFC 9728), which authorization servers it trusts. Clients must use Resource Indicators (RFC 8707), so that an access token is bound to one specific server and cannot be reused by a malicious server.

PKCE

PKCE (Proof Key for Code Exchange) is an OAuth security extension that prevents an intercepted authorization code from being exchanged for a token by an attacker. In the MCP authorization specification, the Authorization Code flow with PKCE is the mandatory flow for clients connecting to remote MCP servers — there is no permitted variant without it.

Prompt (MCP primitive)

Within MCP, a prompt is a predefined prompt template or workflow that the user invokes explicitly — visible as a slash command in clients such as Claude Code and Gemini CLI. Unlike tools (which the model drives) and resources (which the application manages), control lies with the user. Servers use prompts to offer proven working methods ready-made.

Prompt injection

Prompt injection is an attack in which malicious instructions are hidden inside data the language model processes — for example in a web page, email or tool result. The model may follow those instructions as if they came from the user. Within MCP, tool results are a major injection channel; the official Security Best Practices and human approval of actions are the primary defences. More on our security page.

Registry (MCP Registry)

The official MCP Registry (registry.modelcontextprotocol.io) is the open catalogue of metadata for publicly available MCP servers, launched in preview on 8 September 2025. The registry hosts no code, but server.json metadata pointing to packages on npm, PyPI or Docker Hub. According to the official registry API, it listed around 9,650 servers in May 2026. See also trusted sources.

Remote vs. local server

A local MCP server runs as a subprocess on the user's machine and communicates via stdio; a remote server runs elsewhere (cloud, data centre) and is reachable via Streamable HTTP with OAuth authorisation. The practical rule of thumb: stdio for local and personal use, Streamable HTTP as soon as something needs to be shared, hosted or accessed by multiple users.

Resource

A resource is one of MCP's three server primitives: read-only context or data addressable via a URI — think files, database records or documents. The host application (not the model) decides which resources are added to the model context, and clients can subscribe to change notifications. Resources supply information without executing anything.

Rug pull

A rug pull is an attack in which an MCP server first behaves trustworthily and only changes its tool definitions or behaviour after installation or approval — for example via an update that adds malicious instructions. Because the user already trusts the server, the change goes unnoticed. Pinning fixed versions and monitoring changes in tool definitions are the standard countermeasures; see security.

Sampling

Sampling is the client primitive that lets an MCP server have the client's language model generate a completion, without needing to hold an API key itself. Note: sampling is formally deprecated as of spec version 2026-07-28, with a migration window of at least twelve months. The recommended replacement is for servers to call an LLM provider API directly. So don't build new servers around it.

Scopes

Scopes are the OAuth permissions that determine what a client may do at an MCP server on the user's behalf, for example read-only or also write. Since spec version 2025-11-25, MCP supports incremental scope consent via the WWW-Authenticate header: a client starts with minimal permissions and only requests additional scopes at the moment an operation actually needs them.

Spec version

MCP spec versions are dates, not version numbers: 2024-11-05 (launch), 2025-03-26 (Streamable HTTP, OAuth), 2025-06-18 (structured output, elicitation), 2025-11-25 (current stable) and 2026-07-28 (release candidate, final at the end of July 2026). Client and server negotiate at startup which version they speak. Relevant for businesses: the 2026-07-28 revision contains breaking changes, including a stateless protocol core.

SSE (Server-Sent Events)

SSE is a web technology that lets a server stream messages to the client over an open HTTP connection. A source of much confusion: MCP's old separate HTTP+SSE transport has been deprecated since spec version 2025-03-26, but SSE as a technique is not gone — Streamable HTTP uses it internally as an optional streaming mechanism. "SSE is deprecated" therefore refers to the transport, not to server-sent events themselves.

stdio

stdio is the standard transport for local MCP servers: the client starts the server as a subprocess and exchanges JSON-RPC messages via stdin and stdout. The spec advises clients to support stdio wherever possible. The best-known pitfall according to the official documentation: never log to stdout — that channel is reserved exclusively for protocol messages and a single stray print() silently breaks the server.

Streamable HTTP

Streamable HTTP is the transport for remote MCP servers, introduced in spec version 2025-03-26 as the replacement for the old HTTP+SSE transport. A single endpoint (usually /mcp) receives all JSON-RPC messages via POST; the server responds with a single JSON answer or opens a stream for multiple messages. Since 2025-11-25, permanent connections are no longer required: servers may drop the connection and clients resume it.

Tool

A tool is an executable function offered by an MCP server that the language model can decide to call on its own — with the user's approval. Think "create a GitHub issue" or "query the database". Every tool has a JSON Schema for input and output; since spec version 2025-06-18, tools can also return structured output that is validated against a schema.

Tool poisoning

Tool poisoning is an attack in which malicious instructions are hidden inside the description or metadata of an MCP tool. Because the language model reads tool descriptions to decide which tool to call, it can execute hidden commands without the user seeing anything. Reviewing tool definitions before installation and only sourcing servers from trusted places are the basic measures — see security and trusted sources.

Transport

A transport is the channel layer over which MCP messages travel. The spec defines two: stdio for local servers and Streamable HTTP for remote servers; all messages are UTF-8 JSON-RPC. The protocol is transport-agnostic: custom transports are allowed as long as the JSON-RPC framing and lifecycle remain intact. In practice, the choice of transport also determines your security model — process isolation locally, OAuth remotely.

Where to go for more depth?

This glossary provides compact definitions; the underlying concepts are covered in more detail elsewhere on the site. For the architecture and the interplay of host, client and server, read How does MCP work?. Want to get hands-on? The build guide walks you from the first line of code to publication in the registry. And for the risk side — prompt injection, tool poisoning, rug pulls and the countermeasures — there is the security page and the overview of MCP and EU regulation.

Last updated: 2026-07-06