MCP Sampling

Normally your app (the "client") is the one that starts things — it asks the server for a file, a search result, a calculation. The server just answers. Sampling flips that around: the server is the one that starts things. It sends your app a request that says "go ask the AI model this, and bring me back the answer." That's what makes sampling unusual — the arrow points the other way.

"There SHOULD always be a human in the loop with the ability to deny sampling requests." — MCP spec

Think of it like this: the server writes a note asking a question. It hands the note to your app. Your app shows you the note before sending it anywhere — you can approve it or change it. Only then does your app forward it to the AI. When the AI answers, your app shows you that answer too, before handing it back to the server. Two separate "are you sure?" moments, on purpose, so nothing gets sent or returned without a human seeing it first.

"With no server API keys necessary." — MCP spec

The simplest way to give an MCP server AI powers is to just paste your API key into it and let it call the model directly. That works fine on your laptop. It falls apart the moment other people start using your server — now your key is paying for every stranger's request, nobody reviewed what got sent, and there's no record of any of it. Sampling exists so the server never has to hold a key at all — it just asks whoever is running it to make the call, using their own account.

For the server to ask the client something, there has to be an open line between them the server can talk into whenever it wants — like a phone that's always picked up, not one you only answer when you happen to call. Running the server as a local program on the same computer (called "stdio") gives you that automatically. Hosting the server remotely over the web works too, but only if the connection is kept open and tied to one specific client. Turn on the "stateless" setting some teams use to handle more traffic, and that open line disappears — so does sampling.

Sampling wasn't deprecated alone. Two other features that also depend on the server being able to reach the client at any moment got deprecated in the same release: "roots" (the server checking which folders it's allowed to look at) and "logging" (the server telling the client what it's doing while it works). All three share the same weak spot — they all need that always-open line between server and client.

"Server-initiated requests may now only be issued while the server is actively processing a client request." — MCP spec blog, 2026-07-28

MCP wants to let anyone run a server behind a normal load balancer, spreading traffic across many copies of the same server at random. That only works if any copy can handle any request — which means no copy is allowed to keep a private, dedicated line open to one specific client. Sampling needs exactly that private line. When those two goals collided, the spec picked the load-balancer-friendly option and walked sampling back.