Some agent architectures ask one component to run a language-model generation for another. Legacy MCP Sampling is one example.
It may look like a convenient extension point: the server needs analysis, drafting, or a model-assisted decision, so it asks the client to provide it. But the request crosses a meaningful boundary. The server is asking another system to use model access, potentially include context, potentially allow tools, and return an output that could influence a larger workflow.
That is delegation. It needs a contract.
Protocol status, September 2026: The official Deprecated Features registry records that MCP Sampling was deprecated in protocol version 2026-07-28. New implementations should integrate directly with LLM-provider APIs. The controls below apply to legacy Sampling deployments and to provider-direct nested model calls, where the same governance problem remains.
The model host retains important control
The current, deprecated MCP Sampling specification documents a server request for client-hosted LLM sampling. In MCP 2026-07-28, the server carries that request inside an InputRequiredResult, and the client returns the result in inputResponses when retrying the original request. The feature lets clients maintain control over model access, selection, and permissions. It also recommends a human-in-the-loop posture: users should be able to review or deny sampling requests, inspect or edit prompts, and review generated responses before delivery.
That design has an important implication: the server may express what it needs, but it does not automatically own the client’s model capacity, provider relationship, tool permissions, or user attention.
The specification makes this visible in two places:
- servers can express model preferences, but those hints are advisory and the client makes final model selection; and
- tool-enabled sampling is available only when the client has declared support for it.
Those protocol features are not a complete governance system. They are a foundation for one. An application still needs to decide what the request is for, what it may consume, what it may expose, and how its result should be interpreted.
The Sampling Delegation Contract
The Sampling Delegation Contract is a proposed record for a nested model request. It is not a copy of a prompt, a provider configuration dump, or a permanent grant for a server to use any model. It is a compact explanation of why this invocation is acceptable for this parent task, under these limits, at this moment.
- Contract element: Parent task and requester — Question it answers: Which user-visible task needs the generation, and which server requested it? — Why it matters: Preserves accountability across the delegation boundary.
- Contract element: Intended outcome — Question it answers: What bounded analysis, draft, classification, or decision support is expected? — Why it matters: Stops a general model request from silently expanding into open-ended agent work.
- Contract element: Context disclosure posture — Question it answers: What source classes or references may be included, and what must remain excluded? — Why it matters: Makes information sharing a deliberate choice rather than a hidden prompt expansion.
- Contract element: Client-selected route — Question it answers: Which eligible model or configuration did the client choose, and what capabilities were required? — Why it matters: Keeps model selection with the host that owns access, cost, and product policy.
- Contract element: Tool posture — Question it answers: Are tools absent, available within a declared capability, or subject to an additional approval boundary? — Why it matters: Prevents a nested generation from quietly becoming a broader tool-using agent.
- Contract element: Effort and iteration boundary — Question it answers: What time, cost, turn, concurrency, or retry limit applies? — Why it matters: A server’s need for help does not create an unlimited capacity claim.
- Contract element: Human review and denial — Question it answers: What can the user inspect, deny, or approve before the request or result advances? — Why it matters: Preserves a meaningful control point for nested model work.
- Contract element: Result destination and acceptance — Question it answers: Who receives the result, how is it labeled, and what verification still remains? — Why it matters: A generated response is not automatically a verified answer or authorized effect.
- Contract element: Retention and audit summary — Question it answers: What minimal record is needed later without retaining raw prompts or sensitive payloads? — Why it matters: Keeps the delegation reviewable and privacy-conscious.
The contract gives a client a clear stance: it may provide a model service to a server when the request fits the parent task and policy, but it should not disappear as the policy owner merely because the call is nested.
Model Preferences Remain Advisory
The MCP Sampling specification uses abstract priorities and optional hints because a server and client may have different model providers or available models. The server can indicate tradeoffs among cost, speed, and capability, but the client retains final selection.
This is more than an interoperability detail. It prevents a remote component from assuming that it can dictate the user’s model choice, cost posture, or provider relationship.
At the application level, the client should evaluate a sampling request against its own policy:
- Is the requested outcome relevant to the parent task?
- Does the proposed context fit the task’s data and disclosure boundary?
- Does an eligible model route exist under the required quality and resource constraints?
- Is the request asking for tools the client has actually chosen to support?
- Does the user need to review or deny this particular delegation?
- How will the result be labeled: draft, evidence candidate, analysis input, or accepted outcome after separate verification?
The answer can be no. A rejected or narrowed sampling request is an honest policy result, not a failure of the server’s workflow.
Tool use turns a nested generation into a nested agent loop
The MCP Sampling specification allows servers to include request-scoped tool definitions within sampling only when the client declares support for tool use. Those definitions do not need to correspond to registered MCP tools. The client mediates the model request; when the model requests a tool, the server typically executes it and submits the result through a subsequent sampling round. The specification recommends user review, validation, sensitive-data care, rate limits, and iteration limits.
That changes the shape of the delegation. The client is no longer providing only a text generation. It is mediating a bounded model capability while the requesting server may coordinate a tool loop whose results depend on further operations.
Treat that as a separate posture in the contract:
- Sampling posture: Generation only — What the client is providing: A model output over permitted input — Appropriate decision boundary: Check purpose, context disclosure, model route, and result destination.
- Sampling posture: Generation with constrained tools — What the client is providing: A bounded agent loop under declared client support — Appropriate decision boundary: Add tool availability, limits, and user-review policy.
- Sampling posture: Generation requesting a consequential effect — What the client is providing: A proposed action may emerge from the nested loop — Appropriate decision boundary: Require the same current authority and confirmation rules that apply to any other effect.
The MCP Tools specification covers a distinct interface for server-exposed tools, but it makes a complementary point: executable capabilities need confirmation, validation, access controls, timeouts, and audit records where appropriate. A nested model request does not bypass those responsibilities.
Keep Delegation Attached to Explicit Application State
The Multi Round-Trip Requests pattern is stateless at the protocol level. A server can place opaque requestState in an input-required response, and the client must echo it unchanged on retry. If that state affects authorization, resource access, or business logic, the server must protect its integrity and should bind it to the authenticated principal, a short expiry, and the originating request.
Long-running work uses a separate mechanism. The current MCP Tasks extension provides durable handles, polling, mid-flight input, and reconnect support for supported operations such as tools/call; it is not core support for task-augmented Sampling. For provider-direct nested calls or legacy Sampling, the application must retain whatever parent-task state it needs to explain the request and its next safe action.
A durable parent record should show whether the sampling request is:
- proposed but not yet allowed;
- approved and in progress;
- waiting for a user decision;
- completed with a draft or analysis result;
- rejected, declined, or cancelled; or
- superseded because the parent task or data boundary changed.
Without that state, a later model turn may interpret an old request as a standing instruction to spend more model capacity. The contract makes it a time- and task-bound delegation instead.
Separate generated text from accepted work
A nested model output can be useful without being final.
It might be a draft to revise, an explanation to validate, a classification to compare with evidence, or an internal recommendation for the requesting server. The parent task should decide what it means next. It should not present the result as user-approved, factually verified, or externally applied merely because a model returned fluent text.
The Sampling Delegation Contract therefore ends with a result destination and acceptance boundary. A reviewable system can say:
- a server received an analysis draft;
- the result still needs source verification;
- a tool proposal was generated but not executed;
- the user declined the sampling request; or
- the delegation was superseded before a result could be used.
Those are more useful states than a generic “model call succeeded.”
Measure delegated model work by policy fit
Useful metrics are not just request count or token cost:
- purpose fit: what share of sampling requests had a clear, task-relevant intended outcome?
- delegation refusal quality: when a request was denied or narrowed, did the system preserve a useful safe alternative or clear explanation?
- context-boundary compliance: did requests include only permitted source classes and avoid unnecessary data exposure?
- tool-boundary fidelity: did tool-enabled sampling occur only under declared client support and applicable policy?
- route accountability: can a reviewer see that the client, rather than the requesting server, made the final model selection?
- result-honesty rate: how often were nested outputs correctly labeled as drafts, evidence candidates, verified results, or proposals?
- budget containment: did nested calls stay within their declared limits without starving the parent task of resources?
These measures help a platform make delegation useful without turning it into an invisible backchannel for unlimited inference.
A practical adoption path
- Inventory server-initiated model requests and group them by intended outcome.
- Require each request to identify its parent task and a concise purpose before model work begins.
- Define the maximum context classes that may be included and the material that must remain excluded.
- Keep final model selection and quality-floor policy with the client that owns the model relationship.
- Treat tool-enabled sampling as a distinct, higher-boundary capability.
- Set a bounded effort and iteration posture for each request class.
- Give users a review or denial path proportionate to the task and show what a result will be used for.
- Record the final disposition and any acceptance check without retaining raw prompts, secrets, or detailed provider internals by default.
The result is a more legible agent ecosystem: a server can ask for intelligence, while the client still protects the user’s model access, data boundary, capacity, and control.
A Virillio Code Editorial Perspective
Virillio Code Editorial presents the Sampling Delegation Contract as a product-neutral educational framework: when one component asks another to spend model capacity, the request needs its own purpose, limits, review boundary, and disposition. It does not describe a shipped or planned Virillio Code capability.
Sources and further reading
- Sampling — Model Context Protocol — The current specification marks Sampling deprecated and documents client-controlled model access, human review, request-scoped tools, advisory preferences, and iteration limits for legacy deployments.
- Deprecated Features — Model Context Protocol — The official registry records Sampling's deprecation in 2026-07-28 and directs new implementations to integrate directly with LLM-provider APIs.
- Multi Round-Trip Requests — Model Context Protocol — The current protocol carries nested Sampling requests in InputRequiredResult and returns keyed client responses on a retry of the original request.
- Tools — Model Context Protocol — The current specification describes the distinct server-exposed tool interface and its confirmation, validation, access-control, timeout, and audit guidance.
- Tasks — Model Context Protocol Extension — The current Tasks extension provides durable handles, polling, mid-flight input, and reconnect support for supported long-running operations such as tools/call; it is separate from Sampling.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.