Ask for the aspect ratio first: an MCP input_required round trip

MCP multi round-trip requests let a tool answer input_required to ask for an aspect ratio or spend approval before a render, with state in requestState.

5 min readSume
All posts

A render tool can ask the user for the one thing it needs before it spends. In MCP 2026-07-28 multi round-trip requests (MRTR), the server returns resultType: "input_required" with inputRequests and an opaque requestState. The client collects the answers and retries the same call with inputResponses, using a new JSON-RPC id. It works on prompts/get, resources/read and tools/call, per the MRTR pattern page read 2026-10-03.

Why ask before a render

Two inputs change a video render's value and cost: the aspect ratio and the confirmation to spend. Guessing the first wastes a paid job. Skipping the second removes the human from a spend decision. Both are cheap to ask for before the job exists.

Sume's video docs say each model reports its accepted supported_aspect_ratios, supported_resolutions and supported_durations, so the question can offer only valid choices.

The round trip in four steps

The steps below describe the flow for a server you write. The exact shape of each request entry is defined by the spec, so check the pattern page before you implement it.

An aspect-ratio round trip (spec read 2026-10-03)
StepClient sendsServer answers
1tools/call with a prompt and no aspect ratioinput_required with an input request and a requestState
2User picks 9:16 in the clientNothing yet
3Same tools/call with inputResponses and the requestState, new JSON-RPC idValidates the state, then submits the job
4Waits on the returned job idTerminal status and a result

Keep state out of the server

The reason for the pattern is that the server keeps nothing between steps one and three. The pending question lives in requestState, so any instance can finish the call. That is the same stateless goal as the session removal in the same release.

Because the state travels through the client, it must be protected. The spec says to treat it as attacker-controlled; a companion post covers signing it.

How it relates to Sume's own gates

The hosted Sume MCP server documents its own pre-spend controls: an optional dry_run=true for an admission and cost preview, an optional max_spend_usd enforced when provided, and a required idempotency_key on paid tools. The docs describe the key as transport and dedup, not human approval. So a confirmation step is something an agent or your own wrapper adds on top, for example by calling with dry_run first and asking the user before the real call.

{
  "idempotency_key": "launch-clip-001",
  "dry_run": true,
  "max_spend_usd": 2,
  "payload": {"prompt": "Vertical product clip, soft daylight"}
}

Sources

Related posts

More in Developers

All Developers posts

Written by Sume