MCP went from an Anthropic spec to an industry standard in 12 months. The vocabulary moved just as fast, yet most of what you’ll find online still describes the December 2024 protocol, not the one your agents are running on today.
This glossary is current to the November 25, 2025 MCP specification. That’s the version released after Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation. We’ve written this glossary for platform engineers wiring up tools, transports, and auth, and for enterprise architects who have to defend the deployment model in a governance review.
We’ve split it into two parts:
- Part 1: The 15 essential MCP terms. These are deep definitions you can hand to a new hire, with governance notes where they matter.
- Part 2: The full A to Z reference. These are tight definitions for the broader vocabulary, spanning extensions, registry concepts, security primitives, and the rest of the surface area.
A short note on framing: MCP is a protocol, not a product. But protocols don’t govern themselves. Where it’s relevant, we’ve added a short governance lens to flag the control plane question that sits underneath the spec because in practice, that’s where most production decisions actually happen.
MCP in one paragraph
The Model Context Protocol is an open standard for connecting AI applications (hosts) to external tools and data (servers) through a thin client layer. It uses JSON-RPC 2.0 over either stdio (local processes) or streamable HTTP (remote services), authenticates remote calls with OAuth 2.1, and exposes capabilities as a small set of standardized primitives. These include tools, resources, and prompts on the server side, and roots, sampling, and elicitation on the client side. It’s the same protocol whether the agent is running in Claude Desktop, Cursor, ChatGPT, or your own internal copilot. Read more about what MCP is here.
Part 1: The 15 essential MCP terms
Model Context Protocol (MCP)
An open standard, originally introduced by Anthropic in November 2024 and donated to the Agentic AI Foundation in December 2025, that defines how AI applications connect to external tools, data, and prompts. MCP plays a similar role for agents that the Language Server Protocol plays for IDEs: One protocol, many implementations, no vendor-specific connectors per host. The current specification version is 2025-11-25.
Governance lens: MCP standardizes the wire format. It doesn’t standardize who is allowed to call which server, with which model, at which cost. That’s a control plane problem.
Host
The user-facing application that runs the large language model (LLM) and orchestrates one or more MCP clients. Examples: Claude Desktop, Cursor, ChatGPT, VS Code with the agent extension, an internal copilot built on the Anthropic or OpenAI APIs. The host owns the user interface, the session, and, critically, the decision about which servers to trust.
Client
A protocol-level component, instantiated by the host, that maintains a one-to-one connection with a single MCP server. Clients handle the JSON-RPC handshake, capability negotiation, and message routing. A host can run many clients in parallel; each one talks to exactly one server. Most platform teams never write a client by hand as the SDKs handle it.
Server
A program that exposes capabilities (tools, resources, prompts) to clients. Servers can run locally as a subprocess (stdio transport) or remotely as a service (streamable HTTP transport). A single MCP server might wrap a database, a SaaS API, an internal microservice, or a whole bundle of related operations.
Governance lens: This is the unit you actually govern. Sanctioned vs shadow servers, who can publish them, who can install them, what egress they get, and every other meaningful AI governance decision lives here.
Primitive
The collective name for the standardized building blocks that MCP defines. There are three server-side primitives (tools, resources, and prompts) and three client-side primitives (roots, sampling, and elicitation). Each primitive has a defined JSON-RPC method, schema, and lifecycle. Anything outside this set is either an extension (e.g. MCP Apps) or proprietary.
Tool
A server-exposed function that an LLM can invoke to perform an action, such as query a database, send an email, run a calculation, or deploy a service. Each tool has a JSON Schema for its inputs and outputs, plus a description that the model uses to decide when to call it. Tool calls return structured results that can feed into subsequent calls.
Governance lens: Tools are the highest-risk primitive. They mutate state, spend money, and touch production systems. In practice, you want them behind something that handles request validation, rate limiting, per-tool authorization, and an audit log, just as you do for your APIs.
Resource
A read-only piece of context that a server exposes for the model to consume, such as a file, a database row, a search result, or a document. Resources are addressed by URI and can be listed, read, or subscribed to for change notifications. They’re the right primitive when the model needs to know something, as opposed to do something.
Governance lens: Read-only doesn’t mean low-risk. A poorly scoped resource is the cleanest path to data exfiltration through a chat interface.
Prompt
A reusable, parameterized template that the server makes available to the host, typically surfaced as a slash command or quick-action in the UI. Prompts can include arguments, autocomplete, and references to resources. They standardize the patterns a domain expert wants the model to follow without forcing every user to write the prompt from scratch.
Sampling
A client-side primitive that lets a server request an LLM completion from the host, rather than running its own model. The server says “complete this” then the client runs the user’s chosen model and returns the result. This keeps inference, cost, and model choice with the host and lets servers stay LLM-agnostic.
Governance lens: Sampling is where token spend gets interesting. A server can drive substantial inference costs on the host’s account. Track it.
Roots
A client-side primitive that defines the boundaries the server is allowed to operate within, typically file system paths though the concept is more general. The host says “you may operate within these roots and nowhere else.” Servers that respect roots can’t quietly read your home directory because they were asked to summarize one folder.
Elicitation
A client-side primitive, formalized in the 2025-06-18 MCP specification, that lets a server ask the user a structured follow-up question mid-execution. If a tool needs an additional parameter, the server can elicit it from the user instead of guessing or failing. This is schema-defined, so the host can render it as a proper form rather than a free-text prompt.
Transport
The underlying channel over which JSON-RPC messages travel. MCP defines two:
- stdio for local servers running as subprocesses of the host
- streamable HTTP for remote servers reachable over the network
Streamable HTTP replaced the earlier HTTP+SSE transport in the 2025-03-26 MCP spec and uses a single endpoint with optional server-sent event streaming for long-running responses.
Governance lens: stdio servers run inside the user’s machine with the user’s permissions. Streamable HTTP servers run somewhere else, on someone else’s infrastructure. These different threat models require different controls.
JSON-RPC 2.0
The remote procedure call format MCP uses for every message. Lightweight, text-based, and well-supported across SDKs. JSON-RPC defines requests, responses, and notifications (one-way messages with no response). MCP inherits all of that and layers its own method names, including tools/list, tools/call, resources/read, sampling/createMessage, and so on.
Capability negotiation
The handshake that happens during the initialize call, where client and server declare which primitives and features they support. Servers advertise their capabilities (tools, resources, prompts, dynamic list updates), clients advertise theirs (roots, sampling, elicitation), and both sides agree on a protocol version. Anything not declared in the handshake can’t be used in the session.
Authorization (OAuth 2.1)
The auth framework MCP adopted for remote servers in the 2025-03-26 spec. MCP servers are treated as OAuth 2.1 protected resources; clients obtain access tokens and present them on each request. The November 2025 MCP spec made Client ID Metadata Documents (CIMD) the preferred client registration method (with Dynamic Client Registration retained as a fallback), introduced Cross App Access (XAA) for enterprise-managed authorization, and made PKCE mandatory.
Governance lens: Token validation, scope enforcement, and revocation belong at a policy enforcement point you control, not inside each MCP server. Apply the same architectural reasoning as for a normal API.
Part 2: Full A to Z reference
A
A2A (Agent-to-Agent): A separate but related protocol focused on direct agent-to-agent communication, often discussed alongside MCP. MCP connects agents to tools; A2A connects agents to agents.
Agent: In MCP usage, a program that uses an LLM to plan and act through one or more MCP servers. Agents typically run inside a host application.
Agentic AI Foundation (AAIF): A directed fund under the Linux Foundation that took over MCP governance in December 2025. Co-founded by Anthropic, Block, and OpenAI; backed by AWS, Google, Microsoft, and others.
Annotations: Metadata fields a server can attach to tools or resources to give the model and host extra context. For example, a hint that a tool is destructive or read-only.
Asynchronous operation: A protocol pattern, expanded in the November 2025 MCP spec, that lets a tool call return a job handle and complete later. Designed for operations that take minutes or hours rather than seconds.
Audit log: A record of every MCP request and response. Not a protocol primitive but something that the host, the gateway, or the server has to provide.
Authentication: Verifying who is calling. Distinct from authorization (verifying what they can do). MCP’s auth framework covers both via OAuth 2.1.
B
Bidirectional: A property of MCP transports wherein both the client and the server can initiate messages. Servers can push notifications, request sampling, or elicit input; they’re not passive responders.
C
Capability: A feature flag a client or server raises during the handshake to declare what it supports. See capability negotiation above.
Client ID Metadata Documents (CIMD): A client registration approach where the client_id is a URL controlled by the client, and the authorization server fetches the client’s metadata from that URL on demand. Adopted by the November 2025 MCP spec (SEP-991) as the preferred registration method, with Dynamic Client Registration retained as a fallback. Solves the scale problem of every client having to register separately with every authorization server.
Completion: An autocomplete result that a server provides for a prompt argument or resource URI, typically rendered by the host as the user types.
Context: The information available to the LLM when generating a response. MCP exists to deliver context, through tools, resources, and prompts, in a structured, governable way.
Cross App Access (XAA): An MCP authorization extension introduced in the 2025-11-25 spec (SEP-835), also called Enterprise-Managed Authorization. Lets an enterprise identity provider (Okta, Entra, etc.) issue tokens for an MCP server directly, eliminating the per-server OAuth redirect flow. Built on the Identity Assertion Authorization Grant (ID-JAG) draft. Paired with CIMD as the two main authorization additions in the November 2025 spec, and the headline enterprise-readiness change.
Cursor: An opaque pagination token used in list operations (tools/list, resources/list) to fetch the next page of results.
D
Dynamic Client Registration (DCR): An OAuth 2.0 feature that lets clients register themselves with an authorization server programmatically. Was the original MCP answer to the scale problem of unbounded clients meeting unbounded authorization servers. Positioned as a fallback to Client ID Metadata Documents (CIMD) in the November 2025 spec.
E
Elicitation result: The structured response returned when a server elicits input from the user. Includes the action taken (accepted, declined, cancelled) and the data, if any.
Extension: A formally recognized add-on to the base MCP spec, governed via the Specification Enhancement Proposal (SEP) process. MCP Apps (formerly mcp-ui) was the first major extension, formalized as SEP-1865.
H
Handshake: The opening exchange between client and server, consisting of initialize request, initialize response, and an initialized notification. Establishes protocol version and capabilities.
I
Initialize: The JSON-RPC method that opens an MCP session. Carries protocol version, client info, and client capabilities. The server responds with its own info and capabilities.
Inspector: An official debugging tool for testing MCP servers. Lets you exercise tools, resources, and prompts interactively without wiring up a full host.
J
JSON Schema: The schema language MCP uses to describe tool inputs, tool outputs, elicitation forms, and structured outputs. Standard, widely tooled, and what most SDKs expect.
L
Lifecycle: The full sequence of an MCP session: Initialize, operate, shut down. Each stage has defined messages and rules, and a well-behaved client and server follow it explicitly.
LLM (large language model): The model running inside the host that decides which MCP capabilities to invoke. MCP is intentionally model-agnostic; it doesn’t care whether you’re running Claude, GPT, Gemini, or a local model.
M
MCP Apps: An official extension (SEP-1865, early 2026) that lets servers deliver interactive UI components (forms, dashboards, visualizations) to compatible hosts. Formerly known as mcp-ui.
MCP Registry: An open catalog and API for discovering MCP servers, launched in preview in September 2025. Supports public and private sub-registries so organizations can run an internal catalog of approved servers.
N
Notification: A one-way JSON-RPC message with no response expected. Used for things like notifications/tools/list_changed (server tells client its tool list updated) and notifications/initialized (client confirms it’s ready).
O
OAuth 2.1: The authorization framework MCP adopted for remote servers. See authorization in Part 1 of this glossary.
P
Pagination: The mechanism for handling large lists across requests, using opaque cursor tokens. Required for any list operation that could exceed a single response.
Ping: A trivial JSON-RPC method both sides can use to confirm the connection is alive. Useful for long-lived sessions and load balancer health checks.
PKCE (Proof Key for Code Exchange): RFC 7636. Extension to OAuth 2.0 that protects the authorization code flow against interception. Made mandatory for MCP clients in the 2025-11-25 spec, with S256 required where technically feasible.
Progress notification: A server-to-client notification that reports progress on a long-running operation, identified by a progress token the client supplied with the original request.
Prompt template: A specific prompt with parameter slots, surfaced via prompts/list and retrieved with prompts/get. Renders into a sequence of messages the host can hand to the model.
Protected Resource Metadata (PRM): RFC 9728. The mechanism MCP servers use to advertise the location of their authorization server. MCP servers MUST implement it; MCP clients MUST use it for authorization server discovery.
R
Resource subscription: A pattern where a client subscribes to a resource and receives a notification when its contents change. The polling alternative to long-running queries.
Resource template: A URI template (RFC 6570 style) that describes a family of resources rather than a single one. For example, file:///{path} or db://customers/{id}.
Roots boundary: The set of URIs a client has authorized the server to operate within. See roots in Part 1.
Rug pull: An attack pattern where an MCP server changes its tool definitions after the host has approved them, then exploits the looser surface. Mitigated by content hashing, capability pinning, and strict re-confirmation flows.
S
Sampling request: The specific message a server sends (sampling/createMessage) to ask the host to run an LLM completion. The client decides whether to honor it and which model to use.
SDK: Officially maintained client and server libraries. Python and TypeScript are the reference SDKs and C#, Java, Go, Rust, Swift, and Kotlin SDKs are all in active development. Combined SDK downloads exceeded 97 million per month by December 2025.
SEP (Specification Enhancement Proposal): The formal mechanism for proposing changes to the MCP spec. Modeled loosely on Python’s PEP and Rust’s RFC processes; reviewed by working groups under AAIF governance.
Server identity: A property strengthened in the November 2025 spec, giving servers a stable, verifiable identity across sessions and deployments. Foundational for trust decisions and registry verification.
Session: A single end-to-end MCP conversation between one client and one server, bounded by initialize and shutdown.
Shadow AI: Unsanctioned AI tools, models, or MCP servers running inside an organization without governance oversight. The MCP equivalent of shadow IT. Arguably the dominant operational risk in 2026.
Statelessness: A deployment property, formalized in November 2025, allowing MCP servers to run without server-side session state. Important for horizontal scaling, load balancing, and serverless deployments.
stdio: The local transport. Client and server communicate over the server process’s standard input and output. Default for MCP servers running as subprocesses of the host.
Streamable HTTP: The remote transport, introduced March 2025: a single HTTP endpoint that accepts POST requests and can stream responses via server-sent events. Replaced the earlier HTTP+SSE design.
Structured output: A tool result returned as schema-validated JSON rather than free text. Introduced in the 2025-06-18 spec, it makes tool chaining far more reliable because downstream tools can parse upstream output without LLM mediation.
T
Tool annotation: A hint attached to a tool definition (e.g. readOnlyHint, destructiveHint, idempotentHint) that gives the host and the model a better sense of what the tool actually does. Hints, not guarantees.
Tool call: A single invocation of a tool. The unit of action in MCP. Every tool call should be authenticated, authorized, logged, and ideally rate-limited.
Tool poisoning: A class of attack where a malicious server defines tool descriptions designed to manipulate the LLM’s behavior. For example, instructing the LLM to exfiltrate data on the next call. Defended against by sandboxing, server allowlisting, and reviewing tool definitions.
Transport security: TLS for streamable HTTP. OS-level process isolation for stdio. The minimum bar, with most production deployments adding network policy, mTLS, or a gateway in front.
U
URI scheme: The prefix that identifies a resource type, including file://, db://, https://, and custom schemes a server defines. Resources are always addressed by URI.
W
Working group: A topic-focused group within MCP governance (transport, auth, registry, etc.) responsible for reviewing SEPs and proposing spec changes. The mechanism through which the protocol evolves.
The MCP architecture in one paragraph (recap)
A host application loads an LLM and instantiates one or more clients. Each client connects to exactly one server over either stdio or streamable HTTP, using JSON-RPC 2.0 for messages and OAuth 2.1 for remote auth. They exchange a handshake that negotiates capabilities and protocol version. Once connected, the client can list and invoke server-side primitives – tools (actions), resources (data), and prompts (templates) – while the server can use client-side primitives – sampling (run a completion on the host’s model), roots (operate inside declared boundaries), and elicitation (ask the user a structured follow-up). Everything else (registries, extensions like MCP Apps, asynchronous operations, structured outputs) sits on top of that core.
What this means for API and AI governance
MCP solves the connector problem, not the governance problem. The protocol gives you a standard way to wire any agent into any tool. What it deliberately leaves to you is:
- Which servers your organization sanctions
- Who can publish them
- Which models can call which tools
- What the cost ceiling per session looks like
- How you audit tool calls when something goes wrong
- How you stop a malicious or compromised server before it does damage
These are not new problems. They’re the same problems any platform team faces with APIs: Discovery, identity, policy, observability, lifecycle. The difference is that MCP servers are spinning up faster than most governance models can absorb, and the consequences of getting it wrong now include autonomous agents acting on behalf of your users.
The solution is Tyk MCP Gateway. Speak to the Tyk team to find out more.