Sampling, and why it is being retired

Sampling, and why it is being retired

A sampling request carries messages, optional modelPreferences (name hints plus cost, speed and intelligence priorities), a systemPrompt (which the client may modify or ignore), maxTokens (required, and the client must respect it), and optionally temperature, stopSequences and metadata (which the client may ignore), tools and toolChoice. The reply carries role, content, model and a stopReason (end of turn, stop sequence, max tokens, or tool use). The specification says there should always be a human in the loop who can deny, review and edit the request and review the response.

The host's side is where the controls live, and the example host shows each of them with a greedy server that asks for 100,000 tokens, 50 times, with everyone's context:

includeContext (the request to include other servers' context) is itself deprecated, for the reason the last two rows show: it lets a server read what it was never shown.

Tool use inside sampling

A sampling request can offer the host's model tools, and the server runs the loop: model asks for a tool, server runs it, server sends the result back, repeat. The page's rules are precise and the example checks them with a small validator: every tool_use must be matched by a tool_result with the same id, all results must be in one user message that contains only results, and there should be an iteration limit. The validator accepted the correct shape and rejected a missing result, results mixed with other text, and a tool use with no result at all. In the example's weather tool, two cities took 2 model calls and 3 client rounds. The tool also carries a round limit of its own (three), which this run did not reach.

Who is the control?

A server that asks "are you sure?" is polite. It is not a control, because the server's author decides whether to ask, and a careless or hostile author simply does not.

In the example, the same 5000 "gift" expense was submitted by submit_expense (which asks) and submit_expense_quick (which does not). Without a host gateway, the polite tool asked 1 question and the quick one asked 0 and both submitted. Behind a host gateway that asks the person before running any tool not marked read-only, both submitted 0: the person declined, and nothing the server wrote could change that.

Use the server's own questions as a convenience (they carry exactly the details of the action) and the host's approval as the rule.

A checklist

1. Ask first, act last. Nothing irreversible before your final question; the body runs again each round.
2. Seal the state. Sign it (or encrypt it), bind it to the person and the request, give it a short life, and never put a secret in a signed-only token.
3. Enforce one-time actions on the server. A valid token can be replayed until it expires.
4. Check capabilities before asking, and return a message for the model, not a crash, when the client cannot.
5. Treat accept, decline and cancel differently, and write error text that says what happened and what to do.
6. Never ask for a secret in a form. Use URL mode, and keep third-party tokens on the server.
7. Bind a URL flow to the user who started it. Check the identity of the person who completes it.
8. Limit your own loops. Rounds, tool iterations, tokens. The client should limit them too.
9. As a host, cap tokens, count calls, review requests, and leave other servers' context out.
10. Put the real approval in the host. A server's question is not a control.
11. Do not build new servers on sampling or roots. Plan for their removal, and support the earlier revision only as long as you have clients that need it.

For the curious Why requestState is untrusted

The client carries the state between rounds, so the person, or anything on the client, can change it. Seal it, bind it to the person and request, expire it, and keep a server-side record for one-time actions. Sampling is described as being retired, so this module treats it as legacy and shows the controls a host should keep if it still supports it.