MCP unsupported arguments: move the field into payload

The hosted Sume MCP server at https://mcp.sume.com/mcp takes a small set of top-level arguments per tool: usually idempotency_key, payload, and for paid tools dry_run and max_spend_usd. Everything that describes the job goes inside payload. If a model puts a payload field next to payload, for example quality, the call is refused with the error code unsupported_tool_arguments, and the tool does not run.

What the error contains

The tool result is an error with the message "<tool> received unsupported arguments". The data names the unexpected keys. When every unexpected key is a known payload field for that tool, the error adds hint set to move_to_payload, plus payload_keys listing them. A key that belongs nowhere gets no hint, only the plain list.

The server also builds an adjustments array, one entry per key. Each entry has path, from, to and reason. A key that should move has to set to payload.<key>. A key that the payload already holds is marked to drop, with to set to null, and the payload copy is never overwritten.

The corrected payload entry

When at least one key moves, the array ends with an entry whose path is payload and whose to is the full corrected payload. Its reason tells the client to retry the tool once with exactly this payload and the same idempotency_key. That is the point: the fix is one call, not a re-derivation by the model.

One safety rule limits this. If the corrected payload would not survive MCP redaction unchanged, the server leaves out the combined entry and lists only the per-key moves. Fields like webhook_url, callback_url, source_url and signed URLs are redacted in error data, and copying a [redacted] value into a retry would be worse than having no copy.

{
  "idempotency_key": "order-8823-clip-1",
  "quality": "high",
  "payload": { "prompt": "a slow product turntable" }
}

// fix: move the key
{
  "idempotency_key": "order-8823-clip-1",
  "payload": { "prompt": "a slow product turntable", "quality": "high" }
}

Handling it in a client

Keep the same idempotency_key on the retry. The first call did not run, so reusing the key is safe, and if you had changed the key you could pay for two jobs after a later network retry. Limit repair to one attempt, then surface the error. Do not loop on a message that names the same key again.

• Read data.code first: unsupported_tool_arguments.
• If data.hint is move_to_payload, apply adjustments in order.
• If a payload entry exists, send it as is. If not, apply the per-key moves.
• Retry once with the same idempotency_key.