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.

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.
| Step | Client sends | Server answers |
|---|---|---|
| 1 | tools/call with a prompt and no aspect ratio | input_required with an input request and a requestState |
| 2 | User picks 9:16 in the client | Nothing yet |
| 3 | Same tools/call with inputResponses and the requestState, new JSON-RPC id | Validates the state, then submits the job |
| 4 | Waits on the returned job id | Terminal 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
- Browser voice app that starts Sume jobs: keep the key on your server
Voice apps run in the browser over WebRTC, but Sume keys belong on a server. A route handler that holds the key, allowlists models, reuses idempotency keys.
- C2PA 2.2: file types that can carry credentials vs Sume outputs
C2PA 2.2 manifests can be embedded in JPEG, PNG, WebP, SVG, MP4, MOV and more. How that list lines up with the formats Sume image and video jobs return.
- C2PA 2.2 in plain terms: manifests, hard and soft bindings
C2PA 2.2 describes signed manifests with hash-based hard bindings and fingerprint or watermark soft bindings. What that implies after a re-encode or trim.
- Watch the Sume video catalog for new ids and changed limits in Python
Fetch GET /v1/videos/models, save a snapshot and diff new ids, removed ids and changed durations or resolutions. A Python script, testable offline.
Written by Sume