Community-maintained FDE reference. Not an official Vercel or Anthropic project. About this project

Glossary

Audience:engineer architect security non-technicalMCP spec 2026-07-28

Plain-language definitions of the Model Context Protocol (MCP) and Vercel platform terms used throughout this repository. Terms are listed alphabetically; cross-references are in-file anchor links, so you can follow a chain of “See also” links without leaving the page. Protocol terms follow the 2026-07-28 spec revision; Vercel terms follow the live Vercel documentation. Wire status: the pinned stack (mcp-handler 2.1.1 on @modelcontextprotocol/server 2.0.0) serves the 2026-07-28 contract natively over Streamable HTTP and falls back to stateless 2025-11-25 Streamable HTTP for legacy clients; the SDK Client defaults to that legacy handshake unless you opt in to modern version negotiation, so the examples’ in-memory test suites exercise only the legacy path.

Adapter

An adapter is a thin server-side layer that exposes an existing system (a REST API, a database, a SaaS product) as MCP tools, resources, or prompts without changing the system underneath. It is the workhorse pattern for bringing MCP to software that predates the protocol. On Vercel the natural shape is one Function route per backend, holding that backend’s scoped credential and nothing else.

Role: implemented inside a server.

See also: facade, server, sidecar, tool.

Cancellation

Cancellation asks the receiver to stop work on an in-flight request and free its resources. How it is signalled depends on the transport: over Streamable HTTP the client closes the HTTP response stream of the request it wants cancelled, and the server MUST treat that close as cancellation; over stdio, where there is no per-request stream, it is the notifications/cancelled notification. Either way it is strictly best-effort: the receiver may already have finished, and any side effects that landed before the notification arrived stay landed. On serverless this is sharper than it sounds: a function invocation that has already returned cannot be un-run, so design command tools to be idempotent rather than counting on cancellation.

Role: either side may send it; the receiver decides how (and whether) to honor it.

Capability negotiation

Capability negotiation is how the client and server learn which optional protocol features the other supports: tools, resources, prompts, elicitation, and so on. As of 2026-07-28 there is no opening handshake to negotiate in (SEP-2575): the client carries its capabilities on every request in _meta under io.modelcontextprotocol/clientCapabilities, and the server advertises its own capabilities, supported protocol versions, and identity through the mandatory server/discover request, which a client may call up front or use as a compatibility probe. Each side may only use features the other side advertised, which is what lets old and new implementations interoperate without version sniffing.

Role: performed jointly by client and server, per request rather than per connection.

See also: discovery, initialization, MRTR.

Client

A client is the component inside a host that owns exactly one connection to one server and speaks MCP over a transport. A host runs one client per connected server, which is a deliberate isolation choice: no server sees another server’s traffic, capabilities, or state.

Role: lives inside the host; talks to exactly one server.

Consent is explicit user approval gating a sensitive action: invoking a tool, attaching a resource to the model’s context, or answering an input_required result that asks for user input (see MRTR). MCP places consent in the host because only the host can put a real question in front of a real user. A server that claims “the user already agreed” is asserting something it cannot know.

Role: enforced by the host; never delegated to the server.

See also: elicitation, host, MRTR, trust boundary.

Deployment Protection

Deployment Protection is Vercel’s project-level access control over who can reach a deployment’s URLs, combining a protection method (Vercel Authentication, password, trusted IPs) with a protection scope (which environments it covers). It matters here because a preview deployment of an MCP server is a live internet endpoint; without protection, anyone who learns the generated URL can call your tools. Automated callers use scoped bypass tokens rather than turning protection off.

Role: platform-level gate in front of a deployed server.

Discovery

Discovery is how a client learns what a server currently offers: it calls the list methods (tools/list, resources/list, prompts/list) and, if it opted in via subscriptions/listen, re-runs them when a change notification arrives on that stream. As of 2026-07-28 list results carry required ttlMs and cacheScope fields (SEP-2549), so a client knows exactly how long and how widely it may cache them; servers SHOULD also return tools in deterministic order. Treat the results as a live inventory with an explicit expiry, not a static contract.

Role: client-initiated, server-answered.

Elicitation

Elicitation is the capability that lets a server ask the user for structured input in the middle of an interaction. As of 2026-07-28 it rides the MRTR pattern (SEP-2322): instead of sending an elicitation/create request to the client, the server answers the original request with resultType: "input_required" and an inputRequests entry describing what it needs; the host puts the question to the user, and the client retries the original request with the answer in inputResponses. Two modes remain: form mode, where the host renders a flat schema of primitive fields, and URL mode, where the user completes a step in the browser (an OAuth grant, a payment page); the URL-mode completion notification and elicitationId from 2025-11-25 are removed, because the retry itself carries the outcome. The user can accept, decline, or cancel, and a well-built host and server treat those three outcomes distinctly: a decline is an answer, not an error.

Role: server-signaled, host-mediated, user-answered.

Facade

A facade is a single MCP server that fronts several backend systems and presents them as one namespaced surface of tools and resources. You gain a simpler client experience and one place to enforce policy; you pay with a single process that spans every backend credential, which concentrates blast radius. On Vercel the facade’s front door is Routing Middleware or rewrites, with the Firewall and rate limits attached at the same edge.

Role: server-side architectural pattern.

Fluid compute

Fluid compute is Vercel’s execution model for Vercel Functions: instances handle multiple concurrent invocations and are kept warm and reused when possible, which cuts cold starts and cost. The trap for MCP authors is treating that reuse as a promise. Instance reuse is a performance optimization, never a correctness guarantee, so module-level variables must never hold cross-request state; two requests from the same conversation can land on different instances, and an idle instance can vanish between them.

Role: execution model underneath every Vercel Function in this repository.

Global Config (formerly Edge Config)

Global Config (formerly Edge Config; the old documentation URL redirects to the new one) is Vercel’s globally replicated key-value store optimized for very fast reads from Routing Middleware and Vercel Functions, with writes applied without a redeploy. For MCP servers it is the right home for data you read on every request but change rarely: feature flags, tool kill switches, coarse allowlists and denylists. It is not a database and not a secrets store; keep credentials in environment variables and job state elsewhere.

Role: platform configuration store read by middleware and functions.

Host

The host is the AI application the user actually touches: a desktop assistant, an IDE, an agent runtime. It owns the user experience, enforces consent, holds user credentials, and runs one client per connected server. In MCP’s security model the host is the only component with direct user trust, which is why so many obligations land on it.

Role: top of the stack; the only component the user directly trusts.

See also: client, consent, orchestrator, server.

Initialization

Initialization was the opening initialize/notifications/initialized handshake that began every connection in revisions through 2025-11-25. The 2026-07-28 revision removes it (SEP-2575): every request now carries the protocol version and client capabilities itself, in _meta under io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities; clients SHOULD send io.modelcontextprotocol/clientInfo per request, servers SHOULD return io.modelcontextprotocol/serverInfo per result, and a version mismatch fails the individual request with UnsupportedProtocolVersionError rather than failing a handshake. A client that wants the old up-front view calls server/discover. You will keep meeting the handshake in the wild during the deprecation window, including from current SDKs, so the term stays in this glossary.

Role: removed as a required first step; replaced by per-request self-description.

JSON-RPC

JSON-RPC 2.0 is the message format MCP builds on: requests that expect responses, responses that carry results or errors, and notifications that expect nothing back, all encoded as JSON. MCP layers method names, per-request metadata, and capability semantics on top; the transports carry these messages but never change their meaning.

Role: wire format shared by clients and servers on every transport.

MRTR

A Multi Round-Trip Request (MRTR) is the 2026-07-28 pattern that replaces server-initiated requests (SEP-2322). When a server needs something from the client mid-request (user input, a model completion, a filesystem path), it does not open a reverse channel; it answers the original request with resultType: "input_required" and an inputRequests map, keyed by server-assigned ids, describing what it needs. The client gathers the answers and retries the original request, on a fresh request id, with inputResponses attached and a byte-exact echo of the server’s opaque requestState, which is how the server correlates the retry without holding memory between invocations. Every result in 2026-07-28 carries a required resultType of "complete" or "input_required"; results from earlier-protocol servers that omit it are treated as complete. The pattern is why a server can ask questions and still run as a stateless Vercel Function: all pending state rides in the messages.

Role: server-signaled, client-driven, host-mediated.

See also: consent, elicitation, sampling, session.

OIDC federation

OIDC federation is Vercel’s mechanism for giving a deployment a verifiable identity instead of a stored secret: Vercel’s identity provider signs a short-lived token (exposed as VERCEL_OIDC_TOKEN in builds and delivered as the x-vercel-oidc-token request header in functions, read with getVercelOidcToken() from @vercel/oidc), and a cloud provider that trusts the issuer exchanges it for temporary, scoped credentials. For MCP servers this is the backbone of least privilege on the platform: the backend credential never sits in an environment variable, cannot leak from one, and expires on its own.

Role: platform identity mechanism replacing long-lived backend credentials.

Orchestrator

An orchestrator is a host or agent runtime that composes many MCP servers into one coherent tool layer for a model: it decides which server to call, in what order, and with what supervision. It is a client-side concern; there is no server-to-server path in MCP, so all composition flows through the component that holds the user’s trust.

Role: host-side pattern; not part of any single server.

See also: client, facade, host, sampling.

Preview deployment

A preview deployment is the deployment Vercel creates for every push to a non-production branch, published at its own generated URL. For an MCP server, a preview is not a staging sandbox; it is a working protocol endpoint on the public internet, with whatever credentials its environment variables grant. Unless Deployment Protection covers previews, treat every push as a small production release, because the internet will.

Role: per-branch deployment environment for a server.

Progress notification

A progress notification is an out-of-band message a server sends while a long-running request is still in flight, keyed to a progress token the client supplied. It is purely informational; the real result still arrives as the response to the original request, and a client must be prepared for progress to stop without warning. Request-scoped notifications like progress stay on the originating request’s response stream in 2026-07-28.

Role: server-emitted during a request the client initiated.

Prompt

A prompt is a reusable, parameterized message template a server publishes for the user to pick, such as “summarize this incident” or “draft a changelog entry.” Prompts are user-controlled by design: the model never fires one on its own, and the host surfaces them as explicit user choices. That control boundary is the point; do not blur it by having tools invoke prompts.

Role: defined by the server, surfaced by the host, invoked by the user.

Resource

A resource is a unit of context a server offers for the host to attach to the model’s context window: a file, a record, a query result, a document. Resources are application-controlled; the host or user decides what gets read and shared, not the model and not the server. Anything a resource contains ends up in front of an LLM, so servers should minimize what each resource exposes.

Role: defined by the server, selected by the host or user.

See also: prompt, resource template, root, tool.

Resource template

A resource template is a parameterized URI pattern (for example db://{table}/{id}) that a server advertises so a client can construct concrete resource URIs on demand. Templates let a server describe an unbounded family of resources without enumerating them; every parameter that arrives through one is client-supplied input and must be validated like any other.

Role: server-defined, client-instantiated.

Root

Deprecated in 2026-07-28 (SEP-2577), with a window of at least twelve months; migrate to passing paths through tool parameters, resource URIs, or server configuration. A root is a filesystem boundary the client declares to scope where a server may operate; during the window a server may still request the list by returning an input_required result carrying a roots/list input request (see MRTR) and receives the roots in inputResponses on the retry; the notifications/roots/list_changed notification is removed. Roots mattered chiefly for local servers over the stdio transport; a server deployed as a Vercel Function has no shared filesystem with the user, so a remote server that requests roots deserves a raised eyebrow.

Role: client-declared, server-respected; deprecated.

Routing Middleware

Routing Middleware is Vercel code that intercepts a request before it reaches your functions or the cache: it can rewrite, redirect, set headers, or reject outright. For MCP servers it is the platform’s front door, the natural place for facade-style routing, Origin checks, and coarse gating driven by Global Config. The 2026-07-28 revision makes the front door smarter: every Streamable HTTP POST must carry Mcp-Method and Mcp-Name headers, so the edge can route and rate-limit per tool without parsing the body. Keep it thin; policy that needs the request body or the authenticated principal belongs in the handler, not the edge.

Role: edge-level request interception in front of a server.

Sampling

Deprecated in 2026-07-28 (SEP-2577), with a window of at least twelve months; migrate to calling an LLM provider API directly from the server (on Vercel: the AI SDK or AI Gateway). Sampling let a server ask the host to run a model completion on its behalf; as of 2026-07-28 there is no server-initiated sampling/createMessage request, and during the window the ask is expressed through the MRTR pattern instead. Where it survives, the host stays in charge: it can deny the request, edit the messages, pick the model, and demand consent, because a sampling request is a server spending the user’s tokens and the user’s trust.

Role: server-requested, host-fulfilled; deprecated.

See also: consent, elicitation, host, MRTR, trust boundary.

Sandbox

Vercel Sandbox is an ephemeral, isolated Firecracker microVM for running untrusted or model-generated code, with its own filesystem and a networkPolicy egress allowlist that defaults to denying outbound traffic you did not name. In this repository it is the Vercel-shaped answer to the sidecar pattern’s isolation job: a tool that must execute arbitrary code does it inside a sandbox, not inside the server’s own function.

Role: isolation primitive a server invokes for dangerous work.

Server

A server is the component that exposes tools, resources, and prompts over MCP. Good servers are small, focused, and hold the credentials for exactly one domain. On Vercel a server is not a resident process: it is a route whose handler runs as Function invocations, with no memory it did not explicitly externalize. Design for that honestly and everything else gets easier.

Role: the component that holds integration logic and backend credentials.

See also: adapter, client, host, Vercel Function.

Session

The 2026-07-28 revision removes protocol-level sessions from the Streamable HTTP transport (SEP-2567): there is no Mcp-Session-Id header, list results no longer vary per connection, and any state that must span calls travels as an explicit server-minted handle passed back as an ordinary tool argument. What remains of “session” is a host-side notion, the conversation the user is having, which no longer has a protocol identifier. This is the change that makes serverless the happy path rather than a workaround: on Vercel there was never a live connection to hang state on, and now the protocol agrees. During the deprecation window you will still see Mcp-Session-Id from peers speaking 2025-11-25 and earlier.

Role: removed from the protocol; state rides in handles the server mints.

Sidecar

A sidecar is an MCP server run as a separate process or container beside the system it serves, isolating credentials, dependencies, and blast radius. Vercel has no pod-with-two-containers, so the pattern reshapes rather than translates: per-request isolation maps to Sandbox, and a long-lived service sidecar becomes a separate Vercel project gated by Deployment Protection.

Role: deployment shape for a server.

See also: adapter, sandbox, server, trust boundary.

Stdio transport

The stdio transport carries MCP messages over a child process’s standard input and output: the host spawns the server and owns its lifetime. Messages flow on stdout, and stderr is reserved for the server’s own logging. It remains the right choice for local development and CLI tooling, but nothing deployed to Vercel uses it; there is no child process to spawn inside someone else’s browser tab.

Role: connects a locally spawned server to a host’s client.

Streamable HTTP transport

Streamable HTTP is MCP’s remote transport and the primary transport in this repository: the client POSTs JSON-RPC messages to a single endpoint, and responses arrive as JSON or as an SSE stream scoped to that request. The 2026-07-28 revision reshapes it around statelessness: protocol sessions and the Mcp-Session-Id header are removed (SEP-2567), the standing GET stream is replaced by an opt-in subscriptions/listen request whose response stream carries change notifications (SEP-2575), SSE resumability is removed so a client re-issues a request whose stream broke (there is no redelivery), and every POST must carry the Mcp-Method and Mcp-Name headers so edges can route without reading bodies (SEP-2243). Servers must still validate the Origin header and reject bad origins with 403. Per-request statelessness is exactly why it fits Vercel Functions.

Role: connects a remote server to a host’s client; the default on Vercel.

Tool

A tool is an action a server exposes for the model to invoke: “create ticket,” “run query,” “send message.” Tools are model-controlled, subject to consent and policy enforced by the host, and each declares an inputSchema (any JSON Schema 2020-12 keywords as of 2026-07-28) that is your first and cheapest validation surface. Names should be distinct and action-oriented so models and users can tell tools apart across servers.

Role: defined by the server, invoked by the model, gated by the host.

See also: consent, prompt, resource, tool annotation.

Tool annotation

Tool annotations are optional behavioral hints on a tool: readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. They let a host shape UX, such as requiring stronger consent for destructive tools. The spec is blunt about their security value: clients must treat annotations as untrusted unless the server itself is trusted. An annotation is a label on the box, not a lock on it; enforcement lives in the host and in the server’s own authorization.

Role: server-declared metadata; host-interpreted, never security-enforcing.

See also: consent, tool, trust boundary.

Trust boundary

A trust boundary is a line across which data or authority changes hands and must be re-validated. MCP’s classic boundaries are user-to-host, host-to-server, and server-to-backend. On Vercel they take concrete platform form: internet-to-edge (Firewall and Routing Middleware), project-to-project (Deployment Protection with OIDC-verified callers), and function-to-downstream (scoped credentials via OIDC federation). Every page in the security section is ultimately about one of these three lines.

Role: architectural concept, enforced by the host and the platform together.

See also: consent, host, sandbox, sidecar.

Vercel Function

A Vercel Function is the unit of compute behind every server in this repository: your route handler, compiled into on-demand invocations that scale to zero and back. It runs under Fluid compute, and its maxDuration ceiling (300 seconds on Hobby, 800 on Pro and Enterprise, with an 1800-second extended tier in beta at review time) is the forcing function behind the async-jobs pattern. The one-sentence mental model that prevents the most bugs: a Vercel Function is not a daemon, and an MCP server built on one must never pretend otherwise.

Role: the compute primitive an MCP server deploys onto.

Where to look now

Internals: primitives - the method-level reference behind tool, resource, prompt, and the rest of the protocol surface
Internals: transports - the Streamable HTTP and stdio entries here, at full depth
Internals: serverless sessions - how session, Fluid compute, and Vercel Function fit together in practice
Security checklist - the enforcement counterpart to consent, trust boundary, and tool annotation
Getting started - the host, client, and server mental model with a runnable ten-minute path

Bibliography

Model Context Protocol Specification, Architecture, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/architecture
Model Context Protocol Specification, Versioning, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning
Model Context Protocol Specification, Transports, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/basic/transports
Model Context Protocol Specification, Streamable HTTP, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
Model Context Protocol Specification, Multi Round-Trip Requests, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr
Model Context Protocol Specification, Tools, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/server/tools
Model Context Protocol Specification, Resources, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/server/resources
Model Context Protocol Specification, Prompts, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/server/prompts
Model Context Protocol Specification, Elicitation, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation
Model Context Protocol Specification, Sampling, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/client/sampling
Model Context Protocol Specification, Roots, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/client/roots
Model Context Protocol Specification, Cancellation, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/cancellation
Model Context Protocol Specification, Progress, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/progress
Model Context Protocol Specification, Deprecated Features, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/deprecated
Model Context Protocol, Security Best Practices - https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices
Vercel Documentation, Fluid compute - https://vercel.com/docs/fluid-compute
Vercel Documentation, Vercel Functions - https://vercel.com/docs/functions
Vercel Documentation, Deployment Protection - https://vercel.com/docs/deployment-protection
Vercel Documentation, Preview Deployments - https://vercel.com/docs/deployments/preview-deployments
Vercel Documentation, OpenID Connect (OIDC) Federation - https://vercel.com/docs/oidc
Vercel Documentation, Vercel Sandbox - https://vercel.com/docs/sandbox
Vercel Documentation, Routing Middleware - https://vercel.com/docs/routing-middleware
Vercel Documentation, Global Config - https://vercel.com/docs/global-config
Vercel Documentation, Deploy MCP servers to Vercel - https://vercel.com/docs/mcp/deploy-mcp-servers-to-vercel