# Client-side patterns Canonical URL: https://vercel-mcp-reference.vercel.app/client-side/ Markdown: https://vercel-mcp-reference.vercel.app/client-side.md Audience: engineer, architect, security. MCP spec version: 2026-07-28. Last reviewed: 2026-08-26. Status: stable. Most of this repository looks at MCP from the **server** side: the Vercel Function route that exposes tools, resources, and prompts. This section covers the other half of the connection, the [host](https://vercel-mcp-reference.vercel.app/glossary/#host) and the [clients](https://vercel-mcp-reference.vercel.app/glossary/#client) that live inside it. The host is the application the user actually sees (a chat app, an IDE, a desktop assistant); a client is the connector inside it that speaks the protocol to exactly one [server](https://vercel-mcp-reference.vercel.app/glossary/#server). A host connected to several servers therefore runs several clients in parallel, each an isolated scope for capabilities, state, and credentials. Under MCP 2026-07-28 that isolation is entirely the host's discipline: the protocol-level [session](https://vercel-mcp-reference.vercel.app/glossary/#session) is gone, every request is self-contained, and nothing on the wire ties one call to the next except what the host deliberately carries. Client-side patterns are about the decisions the host owns because no server can make them for it: which servers to connect to, how to merge what they expose into one coherent surface, when to ask the user for [consent](https://vercel-mcp-reference.vercel.app/glossary/#consent), how to treat what a server sends back, how to answer a server's `resultType: "input_required"` reply before retrying the request, and how to keep one server's state and credentials from leaking into another's. These responsibilities sit on the trusted side of the host-to-server [trust boundary](https://vercel-mcp-reference.vercel.app/glossary/#trust-boundary), where the user's data, the model's full context, and every secret live. One Vercel-shaped fact colors everything here: in this repository's world, every server is **remote**. It is a deployment at a URL, reached over the [Streamable HTTP transport](https://vercel-mcp-reference.vercel.app/glossary/#streamable-http-transport), owned by someone who can redeploy it at any time. The 2026-07-28 revision meets that world halfway: it is the stateless revision, so a remote deployment that holds no protocol session is no longer a workaround but the specified shape. The host-side disciplines below are largely platform-agnostic, but the stakes are not: a remote server is external code by construction, and the host is the only line between it and the user. A note on versions before the pages. 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. ## Pages - [Multi-server composition](https://vercel-mcp-reference.vercel.app/client-side/multi-server-composition/) - one client per server, each server its own deployment; merging their capabilities into a single namespaced, host-routed surface, with `server/discover` as the per-server capability probe now that there is no initialize handshake. Backed by `examples/orchestrator-host` (in the repository). - [Consent UX](https://vercel-mcp-reference.vercel.app/client-side/consent-ux/) - when a host interrupts the user with an approval prompt, what the prompt must show, why the gate is fail-closed by default, why server-declared annotations are hints, never authority, and why the MRTR retry passes the same gate as the first dispatch. Backed by the `examples/orchestrator-host` (in the repository) consent gate. - [Sampling-request handling](https://vercel-mcp-reference.vercel.app/client-side/sampling-request-handling/) - how a host brokers a server's `sampling/createMessage` request, now doubly on the way out: sampling is deprecated under 2026-07-28 (SEP-2577, with direct LLM provider APIs as the suggested migration), and server-initiated requests generally are replaced by the MRTR pattern. The human-in-the-loop discipline on that page still applies wherever a host meets an older server. - [Elicitation](https://vercel-mcp-reference.vercel.app/client-side/elicitation/) - how a host supplies the user input a server needs mid-request: under 2026-07-28 the server returns an `input_required` result and the client retries the original request with `inputResponses`, instead of receiving an `elicitation/create` request; form mode versus URL mode, the accept/decline/cancel model, and the never-elicit-secrets rule. - [Tool-result rendering](https://vercel-mcp-reference.vercel.app/client-side/tool-result-rendering/) - treating a tool result as untrusted data, not instructions: dispatching on the required `resultType`, sanitizing what the user sees, re-injecting output as provenance-tagged data, and preferring validated structured output. The host half of MCP's primary prompt-injection defense. - [Credential brokering](https://vercel-mcp-reference.vercel.app/client-side/credential-brokering/) - the host holds the secrets and gives each server only a narrowly scoped, short-lived credential (ideally none), with client-auth tokens and upstream credentials kept strictly separate; includes the token-passthrough anti-pattern and rotation. ## Where to look now - `examples/orchestrator-host` (in the repository) - the one host-side example in the repository. It runs **one client per server**, merges each server's `tools/list` into a single **namespaced** list so two servers' tools can never collide, routes a namespaced call back to the owning client, gates destructive tools behind **one host-owned consent callback** that is fail-closed by default, and surfaces a server's `isError` result as a typed error rather than a success. - [Orchestrator pattern](https://vercel-mcp-reference.vercel.app/patterns/orchestrator/) - the pattern-level view of the same responsibility: the host as the coordination and policy layer over many deployed servers. - [MCP internals overview](https://vercel-mcp-reference.vercel.app/internals/overview/) - the host, client, and server roles in plain language, why each client's scope is isolated, and why consent gating is the host's job; see especially [Security implications](https://vercel-mcp-reference.vercel.app/internals/overview/#security-implications). - `examples/secure-tools-server` (in the repository) - the server side of the consent story: a server that declares its write tool honestly so a real host can gate it. Read it together with the orchestrator example to see server-declared intent and host-enforced consent meet in the middle. ## Bibliography - Model Context Protocol Specification, *Changelog* (sessions removed, stateless initialization, MRTR, deprecations), version 2026-07-28 - - Model Context Protocol Specification, *Multi Round-Trip Requests*, version 2026-07-28 -