MCP’s boundaries: what the protocol standardises and what the host must decide

Where the protocol ends and application policy begins Source 1 Source 2

Model Context Protocol standardises the mechanics of context exchange without stretching into model management. The specification splits into a data layer, which defines the JSON-RPC based protocol including capability and version discovery and primitives such as tools, resources, prompts and notifications, and a transport layer covering connection establishment, message framing and authorisation. The MCP overview is also explicit about the upper boundary: the protocol focuses solely on context exchange and does not dictate how AI applications use language models or manage the provided context. That disclaimer is the heart of any responsibilities map, because it leaves application developers with the design work of handling discovery results, selecting what to give a model, and deciding what the user can see and approve. Source 1 Source 2

Host, client, server: three roles, one connection per server pair Source 1 Source 2 Source 3

The three core roles are host, client, and server. The first-party documentation defines the host as the AI application that coordinates and manages one or multiple clients, the client as the component that maintains a server connection and obtains context for the host, and the server as a program that provides context to clients. The client-concept page sharpens that distinction by contrasting the host, which users interact with and which manages the overall experience and coordinates multiple clients, from clients, which it calls the protocol-level components enabling server connections. The pairing rule matters for mental models: an AI application acting as a host creates one MCP client for each MCP server it connects to, and each client keeps a dedicated connection to its server. Source 1 Source 2

Cloudflare’s terminology section reinforces the same structural point, though as a vendor summary rather than protocol language: each MCP client instance has a single connection to an MCP server and clients live inside MCP hosts. Its documentation separates remote connections over Streamable HTTP authorised with OAuth from local connections over stdio, showing that the transport options sit below the host/client/server roles. Source

What servers expose: tools, resources, prompts and their control models Source 1 Source 2

MCP defines three core server primitives. Tools are executable functions AI applications can invoke; resources are data sources supplying contextual information; prompts are reusable templates that help structure model interactions. Each primitive has a different control model, and that difference determines how much application oversight is needed. The server-concept page describes tools as model-controlled, meaning models can discover and invoke them automatically, so the same page lists application-level controls such as approval dialogs, permission settings and activity logs as ways to add user oversight. Resources are application-driven, with the application choosing how to retrieve, process and present context, and the protocol does not mandate specific UI patterns. Prompts are user-controlled, requiring explicit invocation rather than automatic triggering. Source 1 Source 2

The distinction produces a practical consequence: the protocol tells the client what each primitive is and how to request it, but it does not say how much autonomy a model gets over tools in a particular host. Approval dialogs, permission settings and activity logs are described as application choices, not protocol requirements. A host that exposes tools without any of those controls is still behaving consistently with the standard’s mechanics; it simply has not added the oversight layer the documentation suggests. Source

From tools/list to tools/call: the discovery-then-execution path Source 1 Source 2

The server-concept page gives the clearest view of how tool invocation actually flows. Each primitive type has methods for discovery in the form of the */list methods, retrieval with */get, and in some cases execution with tools/call. Clients use the list methods first because listings can be dynamic; discovery is not a one-time snapshot at startup. In the documentation’s walkthrough, a client sends a tools/list request with no parameters beyond the standard _meta fields, accepting an optional pagination cursor, and the response carries a tools array of metadata for each tool. Source

Tool metadata in the tools/list response includes a unique name, a human-readable title, a description of what the tool does and when to use it, and a JSON Schema inputSchema for input validation. The description is not explanatory window dressing; because models use the tool metadata to decide what to invoke, it functions as an interface contract. After discovery, the client executes a tool with tools/call, using the exact tool name returned in the discovery response rather than a simplified name. That requirement pushes validation work back toward the host: the client must treat the discovered name as authoritative and avoid guessing or normalising it. Source

The protocol standardises the transport mechanics around that discovery, but the surrounding capability management is a host-side duty. The client-concept page describes the application’s MCP client manager connecting to configured servers, storing their discovered capabilities for later use, and deciding which servers can provide tools, resources or prompts and whether they support real-time updates. It also describes the AI application fetching tools from all connected MCP servers into a unified tool registry the language model can access, with the model then calling tools during conversations. The unified registry is an application engineering decision layered above the protocol: MCP defines how tools are listed and called, but the host decides how to combine listings, how to present them, and which capabilities to expose to the model. Source

Client-provided features: elicitation as a server-to-user round trip Source

The relationship is not entirely one-directional. The client-concept page says clients may provide features to servers, which matters when a server needs input it cannot obtain itself. The documented example is elicitation, in which servers request user input that the client gathers before retrying the original request such as tools/call. Elicitation has a form mode, where the client builds and validates an input form from a schema, and a URL mode, where the interaction happens out of band and its data never passes through the client. Source

The form mode is the more direct pattern: the server declares a schema, the client renders and validates the input, then the server retries the interrupted request. The URL mode reflects a different trust boundary, because the client arranges the interaction but does not receive the data. Both modes make the client an active coordinator rather than a passive transport. The protocol describes how the retry is requested; the host still decides what a well-formed form looks like and how a user-facing prompt is displayed, since the specification does not mandate a particular interaction design. Source

Roots communicate boundaries; they do not enforce them Source

Roots are useful as a coordination mechanism, but they are also the clearest evidence of where the protocol refuses to be a security system. The client-concept page describes roots as a client mechanism for communicating filesystem boundaries to servers as file URIs. Crucially, the documentation says they communicate intended boundaries and do not enforce security; enforcement must happen at operating-system level via file permissions or sandboxing. The specification’s requirement level further qualifies the mechanism: servers SHOULD respect root boundaries rather than MUST enforce them, because servers run code the client cannot control. Source

The practical consequence is that roots function as a signal of intent, not a safety guarantee. A client can communicate file URIs the server is supposed to treat as boundaries, and a cooperative server can use those hints when it decides what to expose. A malicious or careless server cannot be constrained by that communication. The available documentation identifies no enforcement mechanism for roots beyond operating-system file permissions and sandboxing, so the host cannot rely on roots alone to isolate a server’s filesystem access. Source

Cloudflare’s deployment advice: focused tools, narrow permissions, descriptions and evals Source

Cloudflare’s Agents documentation provides a helpful counterpart to the MCP pages, but it belongs in a different category. Its best practices are vendor recommendations for the application policy layer, not protocol guarantees and not independently measured performance data. Cloudflare advises server builders not to treat an MCP server as a wrapper around a full API schema, but to build fewer tools optimised for specific user goals and reliable outcomes. The concern is that a complete API surface makes discovery larger and the model’s tool selection less predictable, but Cloudflare does not supply a benchmark or adoption metric showing the size of that effect. Source

Cloudflare’s security advice follows the same pattern: deploy several focused MCP servers, each with narrowly scoped permissions, to reduce over-privileged access and make auditing easier. That is a scoping strategy for applications, not a new permission model in MCP. Its testing advice also sits above the standard: detailed tool-parameter descriptions and eval tests that measure an agent’s ability to use tools correctly, run after updates to the server or tool descriptions to catch regressions. Cloudflare is describing the evaluation and review responsibilities of an application team rather than adding a fourth primitive to the spec. These recommendations may be sensible defaults, but the documentation does not report eval methodology or results that would let an adopter compare them against other practices. Source

Put together, the responsibilities map is straightforward: MCP tells implementers how to discover and deliver context, and it defines the host’s structural duty of maintaining a client per server. It does not tell implementers which tools to expose, which context a model should see, which permissions a user should grant, or which eval tests a team should run. The Cloudflare recommendations are one set of application-layer answers to those questions, framed as advice rather than protocol guarantees, and the advisory status of roots shows the same boundary from the security direction: coordinate boundaries, but enforce them at the operating system. Source 1 Source 2 Source 3 Source 4

Produced through the Singularity Logs automated editorial workflow, with separate factual and editorial AI checks. Source links identify the evidence used.

Updated on 20 October 2026 following a further editorial review.