MCP Glossary

Every term you will see in the Model Context Protocol spec, the official SDKs, and the broader ecosystem — defined in one citable line each, with cross-links to the deeper guides where each concept lives.

Spec

Model Context Protocol (MCP)#: An open standard from Anthropic for connecting AI language models to external tools, data sources, and prompts through a uniform JSON-RPC interface.Released November 2024. The current spec revision is 2025-06-18. It defines how an MCP client (an AI assistant) talks to one or more MCP servers (tool providers) so a new tool can plug into any compatible client without bespoke integration code.See also: What is MCP?
JSON-RPC 2.0#: The wire protocol MCP uses. Every request and response between client and server is a JSON-RPC 2.0 message with a method name, parameters, and an ID.Standardising on JSON-RPC means MCP servers do not invent custom message formats. Methods like tools/list, tools/call, resources/read, and prompts/get are spec-defined verbs every server implements.
Capabilities#: The set of features an MCP server advertises during initialization — typically tools, resources, prompts, sampling, or logging.Capability negotiation lets a client know what to surface to the model. A server that does not declare tools cannot have tools called. The capabilities object also covers experimental and vendor-specific extensions.
Tools#: Named, typed functions an MCP server exposes that the model can decide to call. Each tool has a name, a description, a JSON-schema for its arguments, and an execution path.Tools are the primary primitive most MCPs ship. Examples: filesystem.read_file, github.create_pull_request, postgres.execute_query. The model picks which tool to call based on the description and schema you provide.
Resources#: Read-only content an MCP server exposes by URI — files, log entries, schema docs, or any other addressable data the client can fetch and hand to the model as context.Resources differ from tools in that the model does not call them as functions; the client retrieves them and includes them in the conversation context. Good for "here is the file the agent is editing" style use cases.
Prompts#: Pre-defined prompt templates the server exposes and the client can surface to the user as one-click actions or slash commands.A code-review MCP might expose a "review_pr" prompt that already includes the relevant repo context, so the user picks the prompt instead of typing the same instructions every time.
Sampling#: A spec capability that lets an MCP server ask the client to run a model completion on its behalf — useful for servers that need LLM reasoning to fulfill a tool call.Sampling is opt-in per client and per server. Most clients gate sampling behind explicit user consent because it effectively lets the server delegate work back to the user's model budget.

Architecture

MCP client#: The application that hosts an AI model and connects out to one or more MCP servers. Examples: Claude Desktop, Cursor, VS Code with MCP extensions, Windsurf, Zed.Clients are responsible for spawning stdio servers, opening HTTP connections to remote servers, surfacing each server's tools to the model, and (importantly) requiring user confirmation for destructive tool calls.
MCP server#: A program that exposes tools, resources, or prompts to AI clients via the Model Context Protocol. Servers can run as local subprocesses (stdio) or as remote HTTP endpoints.Every entry in this directory is an MCP server. The server defines what the AI can do: read a file, query a database, call an API. Servers are typically built with the official TypeScript or Python SDK.See also: Browse MCP servers

Transport

stdio transport#: A transport where the MCP server runs as a local subprocess and communicates with the client via standard input and output. Lowest latency, no network round-trip.stdio is the default for local development and personal installs. The client spawns the server with command-line arguments, writes JSON-RPC to stdin, and reads responses from stdout. Trade-off: the server has the same OS permissions as the user.See also: Remote vs local MCP servers
Streamable HTTP transport#: The current spec-recommended transport for remote MCP servers. Uses a long-lived HTTP connection that can stream server-initiated messages back to the client.Replaces the older "HTTP+SSE" transport. Better keepalive semantics, simpler proxy traversal, and aligns with how modern reverse proxies handle bidirectional streams.
SSE transport (legacy)#: The original remote transport — HTTP POST for client→server and Server-Sent Events for server→client. Now superseded by Streamable HTTP but still supported by older servers.If you maintain an SSE-only MCP, plan a migration to Streamable HTTP. Newer clients dual-detect both, but the long-term direction is Streamable.

Auth

OAuth 2.1 (with PKCE)#: The auth flow standardised by the 2025-06-18 MCP spec for remote servers. OAuth 2.0 with the deprecated parts removed, PKCE mandatory, dynamic client registration encouraged.Replaces the previously fragmented auth landscape where every remote MCP defined its own scheme. One client implementation now works against every spec-compliant server.See also: OAuth 2.1 for MCP
Dynamic client registration#: RFC 7591. Lets an MCP client register itself with an MCP server at runtime instead of requiring the server operator to pre-create client IDs.Without it, every new MCP client would need manual onboarding per server. With it, the user installs the MCP, the client registers, the OAuth flow runs, and the user is in — no operator round-trip.
Audience binding#: A spec rule that ties each issued access token to a specific MCP server's audience identifier so the token cannot be reused against a different server.Blocks the classic confused-deputy attack — "I have your token, let me reuse it elsewhere." Servers verify the audience claim on every request; clients do not pass tokens between servers.
API-key auth#: A bearer-token auth model used by most stdio MCPs — the client passes a long-lived key in an env var, the MCP forwards it to the upstream service.Simple and ubiquitous but riskier than OAuth — keys are long-lived, hard to scope tightly, and end up in config files. Preferred for local servers wrapping API-key-based services (Stripe, OpenAI, Brave). Rotate on a cadence.See also: Rotating MCP credentials

Security

Confused deputy#: A class of attack where a privileged actor (an MCP server) is tricked by an unprivileged actor (a third party) into using its privileges in unintended ways.The spec calls confused-deputy out by name because tool-calling agents are particularly susceptible — a malicious page can ride a benign user request into a destructive tool call. Defenses: audience binding, scope-narrow credentials, and explicit destructive-action confirmation.See also: MCP prompt injection
Prompt injection#: An attack where untrusted content (a page, a row, a doc) contains instructions the model interprets as its own — turning tool-calling into remote code execution by proxy.For an MCP-equipped agent, the impact scales with the breadth of installed MCPs. Defenses: capability scoping per conversation, confirmation gates on destructive calls, read-only defaults, and tool-call audit trails.See also: MCP prompt injection defenses
Sandboxing#: Running an MCP server in a restricted execution environment — a dedicated Unix user, a container, or a microVM — to limit blast radius if the server is compromised or buggy.For browser-automation MCPs and code-execution MCPs, sandboxing is the realistic default. The cheapest sandbox is a dedicated OS user; the strongest is a sandbox runtime like E2B.See also: Sandboxing MCP servers
Least-privilege scoping#: Granting an MCP the smallest credential and the narrowest filesystem allowlist that still lets the workflow succeed.The single highest-leverage MCP security move. A read-only single-repo GitHub token is dramatically less dangerous than a full-org PAT, regardless of how well-sandboxed the MCP is.See also: Least-privilege scoping

Ecosystem

MCP registry#: The official, comprehensive list of every published MCP server, hosted at modelcontextprotocol.io. Optimised for completeness, not curation.A registry answers "does an MCP exist for X." A curated directory like Top MCPs answers "what is the best MCP for X." The two are complementary.See also: Registry vs curated directory
MCP directory#: A site that adds metadata on top of the registry — scores, install snippets, comparisons, decision rubrics — to help users pick the right MCP for a job.Top MCPs is a curated directory. PulseMCP and mcp.so are comprehensive directories that index every server. Different optimisation, same ecosystem layer.See also: Directories compared
server.json#: A machine-readable manifest describing an MCP server — name, version, capabilities, transports, and install configuration. Adopted by the MCP Registry as the canonical metadata file.Every MCP detail page on this site exposes a /mcp/<slug>.json variant shaped to the Registry's server.json so an agent can ingest the catalog without scraping HTML.
llms.txt#: A plain-text index that lets LLM crawlers discover the structured content of a site without parsing HTML — a robots.txt analogue for AI retrieval.Top MCPs publishes /llms.txt with a summary entry per MCP and /llms-full.txt with inline install snippets. The same files are also surfaced at /.well-known/llms.txt for agents that probe that path.

Reference

For the authoritative spec text, see the Model Context Protocol specification at modelcontextprotocol.io. For implementation patterns, the official TypeScript and Python SDKs live under the modelcontextprotocol GitHub organisation.

modelcontextprotocol.io →GitHub: modelcontextprotocol →What is MCP? →