What does MCP's Data Privacy principle require of a host before it exposes user data to a server?

## The principle as written Data Privacy is the second of MCP's three key principles in revision 2026-07-28 (the others being User Consent and Control, and Tool Safety). It asks implementations to obtain explicit user consent before exposing user data to servers, not to transmit resource data elsewhere without consent, and to protect user data with appropriate access controls. Notice who the obligations fall on. Every clause is something only the **host** can do, because the host is the component holding the user's data before any of it becomes a request. ## What a server can and cannot see The practical shape of the principle comes from the topology. A host connects one client per server. When the host calls a tool, reads a resource or fetches a prompt, the server receives that request and nothing else. Concretely: - It does **not** receive the conversation. There is no field in which the host's chat history travels, and the spec is explicit that servers cannot read the whole conversation. - It does **not** see other servers. A server has no visibility into which other servers the host has configured, what they returned, or that they exist at all. - It **does** see everything the host put in the request: every tool argument, every prompt argument, the resource URI being read, the declared protocol version and client capabilities in `_meta`, and — if the host sends it — `io.modelcontextprotocol/clientInfo`. That asymmetry is the good news and the trap at once. The isolation is real, but it is only as good as the host's judgement about what to place in a request. A helpfully-designed tool whose parameters invite "any relevant context" is an exfiltration surface, and the model filling those parameters is not a privacy control. ## Consent before exposure, not after The consent the principle demands is prospective. Once data is inside a request that has left the host, there is no protocol mechanism to recall it, no expiry the client can impose on the server's copy, and nothing that constrains what the server does with it afterwards. The specification's own framing is that MCP cannot enforce this at the protocol level — a server that logs, stores or forwards what it received is breaking a promise, not a protocol rule. The design consequence is that a host has to reason about **data classes reaching server identities**, not merely about individual actions. "May this tool run?" and "may this server see this content?" are different questions with different answers, and a consent surface that only asks the first leaves the second unexamined. ## No onward transmission without consent The second clause — do not transmit resource data elsewhere without consent — is aimed at the host too. Data a host obtained from one place should not be quietly routed somewhere else on a server's suggestion. In an agent loop this is the common failure: server A returns content, the model treats it as instruction-bearing context, and server B is called with that content in an argument. Nothing in the protocol forbids the second call; the principle asks the host to treat it as an exposure requiring the user's agreement, and the safest hosts make cross-server data movement a visible event rather than an invisible one. ## Access controls The third clause is deliberately open-ended: protect user data with appropriate access controls. For a remote server, the enforceable part of this lives in the authorization profile — audience-bound tokens so a token minted for one server cannot be replayed at another, and a prohibition on token passthrough so a server cannot forward the user's credential onward. For a locally launched server, there is no token at all: it is a subprocess running with the user's own privileges, so "access control" means whatever the host does about filesystem and network scope before launching it. ## What changed in 2026-07-28 Two things are worth stating precisely. First, the principle count went from four to three: *LLM Sampling Controls*, which included the rule that a server should not see the whole prompt, was deleted when Sampling was deprecated in this revision. The underlying protection — a server does not get the conversation — remains a fact of the architecture and is now discussed under consent and privacy rather than as a principle of its own. Second, because protocol sessions and the `initialize` handshake were removed and MCP became stateless, a host cannot express "the user approved data sharing for this session". The grant is host-side state keyed to the user and the server's identity, applied afresh as each request is assembled. ## How this is asked in interviews Usually as a scenario: a tool takes a free-form `context` parameter, or the candidate is asked what a server can learn about the user. Strong answers separate three layers — what the protocol structurally prevents (the conversation and other servers stay invisible), what the host must decide (what goes in the request), and what is unenforceable once the data has left (retention and onward use, which reduce to trusting the server operator).