Client-side patterns

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 and the clients 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. 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 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, 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, 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, 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 - 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 - 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 - 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 - 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 - 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 - 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 - the pattern-level view of the same responsibility: the host as the coordination and policy layer over many deployed servers.
• MCP 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.
• 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 - https://modelcontextprotocol.io/specification/2026-07-28/changelog
• Model Context Protocol Specification, Multi Round-Trip Requests, version 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr