MCP input_required, inputResponses and multi round trip vs dry_run

In the 2026-07-28 MCP revision, multi round trip means the server answers a request with resultType input_required, and the client retries the request with inputResponses. Sume's hosted tools do not document that exchange. Asking before a paid generation is done with two ordinary calls: one with dry_run=true, then the same call without it.

What is the multi round trip pattern?

From the MCP release post: the server returns resultType of input_required, and the client retries with inputResponses. The post is where the names come from; check the spec for the exact payload before writing a client, since this page only relays those two field names.

How does Sume ask before a paid call?

Sume's playbook for a paid avatar create is for use only when the user explicitly confirms spend. Step one is a call with dry_run=true to review the preview; step two repeats it with dry_run omitted or false to submit. Then you poll with jobs_status or jobs_wait and read jobs_result.

Is idempotency_key the confirmation?

No. The gates table says idempotency_key is a stable key for transport and dedup, not human approval, and it is required on write and paid tools. The confirmation is your agent showing the preview and getting a yes. max_spend_usd adds a cap, enforced only when provided.

Can I use one instead of the other?

Design the agent so the confirm step does not depend on protocol support: the two-call form works on any session that can call the tool. A session needs mcp:write or an API key to see paid tools at all, per tools and gates. If a future Sume server adds input_required, it would be additive; the docs today describe only the dry_run flow.

Which calls need a confirmation step?

The docs say ordinary single creates do not need admission theater, and that a preview is for expensive bursts. So the confirm step is for cases where the cost is large or the user has not yet agreed to spend, such as the paid avatar create in the playbook.

For everything else, submit with a fresh idempotency_key and let the job run. You can still pass max_spend_usd as a cap on any call. It is enforced only when you provide it, so leaving it out means no cap.