MCP Sampling: generation approval is not tool authorization

First separate new adoption from existing use

A third-party MCP server asks your host to generate a model response while handling a tool call. Before enabling that request, decide whether you are adding Sampling to a new implementation or evaluating an existing integration. The official version index checked on 6 October 2026 identifies 2026-07-28 as current.[2] Its Sampling notice says new implementations SHOULD NOT adopt the feature and existing implementations SHOULD migrate to direct LLM-provider APIs.[4]

Deprecated does not mean removed. Sampling remains in the specification during its deprecation window. The derived registry lists the first revision released on or after 2027-07-28 as the earliest eligible removal; actual removal may be later.[4][6] That is neither a support warranty for a particular host nor a reason to add the feature by default.

Our recommendation: evaluate the documented direct-provider direction first for new work. For an existing integration, require evidence for generation permission, response disclosure and the server’s tool executor while planning migration. Direct integration still needs its own credential, permission and spending controls; this comparison does not certify it as safer.

A read-only outer tool does not authorize the inner action

Consider a hypothetical, unexecuted invoice workflow. The host exposes only a read-only invoice-analysis tool. During that operation, the server requests a model generation and supplies an archive_invoice tool definition. The model selects it; the server would execute it in its own environment. No invoice, account, model or tool was used for this example.

This matters because Sampling’s tools array is scoped to the generation request: those definitions need not correspond to registered tools. After receiving tool-use selections, the server typically executes them, appends results and asks for another generation.[4] Knowing the host’s ordinary exposed-tool list therefore does not establish what this server’s nested executor is permitted to do.

The read-only outer selection establishes what the host asked for. It does not authorize archiving an invoice. The positive countercase is a design that shows the supplied sampling definitions to the relevant control, restricts the actual executor to permitted read-only work, and documents generation, disclosure and total-work limits. That could address this specific gap; it still needs implementation evidence. Sampling is not shown here to be intrinsically uncontainable.

Follow the executor, not just the tool name

MCP distinguishes a host application, its client connector and a server providing capabilities.[3] In ordinary host-orchestrated tool use, the client invokes an exposed server function with tools/call.[10] Sampling lets the server request a model generation via the client, inside another server feature, while the client retains control over model access, selection and permissions.[4]

There are two enforcement locations: client/host controls over generation and disclosure, and controls at the server’s actual tool executor. They need not be independent systems, but evidence for one does not establish the other. MCP’s overview explicitly says the protocol itself cannot enforce its security principles.[3]

Establish the actual protocol contract

The legacy 2025-11-25 Sampling contract requires capability declaration during initialization.[1] The current 2026-07-28 contract instead requires sampling on each request, under _meta using the exact key io.modelcontextprotocol/clientCapabilities.[4] That key sits inside _meta; it is not a literal dotted JSON key. Modern and legacy behavior are separate eras, and an implementation may support both.[11]

Current server-to-client requests MUST use Multi Round-Trip Requests (MRTR), replacing the previous standalone wire pattern.[9] The sampling/createMessage method remains, carried inside InputRequiredResult.inputRequests; the generated result returns in inputResponses on a retry of the originating request.[4] Basic MRTR permits InputRequiredResult for prompts/get, resources/read and tools/call, and forbids it on other client requests.[9]

This is a transport-pattern change, not evidence that Sampling disappeared or became a separate extension. The changelog moves Tasks to an official extension as a distinct change.[5] The captured official extension overview supplies no separate Sampling-extension link.[8] That bounded discovery does not exclude experimental or third-party extensions, and a method present in the schema does not prove a deployed client supports it.

Request version-specific documentation for the exact host, client connector, server and transport. Match the capability and exchange behavior they actually use together. This article supplies no endpoint probe or compatibility result.

Separate contract language from implemented controls

Uppercase MUST, SHOULD and MAY have the specification’s normative meaning; lowercase explanatory wording does not carry that same status.[3] The following evidence requests are our proposed enablement criteria, not claims that every implementation supplies them.

Context defaults to none; thisServer and allServers are deprecated, with capability-conditional guidance.[7] Our interpretation: none requests no additional MCP context, not an absence of sensitive content in the server’s messages or generated response. Conversely, an allServers request does not prove disclosure, because the client MAY ignore it.[7]

Sampling also requires matching tool-use/result IDs and tool-only result messages.[4] Those rules establish conversation shape, not action permission, correct outputs or duplicate-effect prevention. A valid transcript is not evidence that archive_invoice was authorized.

A generation cap and a refusal answer narrower questions

A compliant maxTokens limit bounds one generation; the documented server loop can request further generations with tool results appended.[4] Our inference is that the field alone does not bound a whole operation’s cost. Repeated generations, input processing and server-side tools need separate accounting. No monetary threshold, billing model or overspend was measured.

Likewise, toolChoice mode none means the model MUST NOT use tools for that generation.[4] On a final turn, it is not an executor kill switch and does not reverse earlier effects. Require a policy for stopping the relevant generation and tool work, rather than treating one response-setting field as the whole control.

Under modern MRTR the server MUST NOT assume the client fulfills the input requests or retries.[9] Current Sampling says an error or user refusal does not require replaying the initial call with an error message.[4] Legacy rejection guidance instead recommends returning an error.[1] Our proposed control is to preserve a denial rather than automatically fulfill it or route around it; declining a later generation does not establish that earlier work was undone.

Make the enablement choice on the missing evidence

For the invoice example, generation approval plus the host’s ordinary read-only tool list is insufficient when the nested executor’s policy is unknown. Hold tool-enabled enablement for that workload until its scoped definitions and action checks are explained. A documented read-only executor could make an existing integration worth evaluating; it would not authorize invoice mutation.

The remaining deployment choice is unknown: no named host/server pair, configured permissions or enforcement evidence was supplied. The useful result is the boundary to investigate, not a safety verdict, provider ranking or claimed savings.

Method, source conflicts and limits

This is a purposive comparison of primary documents, not a statistical sample, market census or experiment. We read current Sampling, MRTR and Versioning and Compatibility, compared legacy Sampling, and consulted relevant schema, Tools, version-index, overview, changelog, deprecation and extension passages.[1][2][3][4][5][6][7][8][9][10][11] We separated role, capability condition, normative strength and what remained implementation-specific. These documents belong to one MCP publisher family: complementary requirements, not independent empirical confirmation.

Sources were captured on 6 October 2026 KST. Page publication/update dates were not established; edition and retrieval dates are not launch or rollout dates. The version-index URL redirected once to /docs/2026-07-28/learn/versioning, while the fixed legacy and current Sampling pages did not redirect. Official links, rather than a missing legacy path, led to the current documents.

Two documentation tensions remain. The generic overview describes extension negotiation during initialization, whereas the specific modern exchange rules describe per-request capabilities.[3][11] The current Sampling example uses thisServer despite nearby deprecation guidance.[4][7] We use the specific rules and capability/schema guidance, preserve these discrepancies, and infer no deployed defect. Discovery extraction duplicated code tokens; raw source capture was checked separately. No example is offered as a copy-and-run recipe.

No account, credential, model generation, tool execution, SDK or interoperability experiment was involved. Examples are hypothetical and unexecuted. Implementation support and enforcement, adoption, exploit prevalence, latency, model quality, cost and business outcomes remain unmeasured—not zero.