MCP timeline_create provider_fields_not_accepted: no ffmpeg fields

A coding agent that has run ffmpeg a thousand times will try to hand Sume an ffmpeg graph. On the hosted MCP server, the timeline_create tool refuses that on purpose. If the payload carries a provider or encoder control field, the call fails with the code provider_fields_not_accepted and the message that Timeline 1.0 rejects provider/ffmpeg control fields.

The refused keys

The check looks for twelve keys: model, endpoint, provider_endpoint, filtergraph, filter_complex, ffmpeg_args, args, command, codec, preset, crf and expression. The error data carries the first offending key in a field property, and a next_action of remove_provider_ffmpeg_fields.

The check runs before the generic allowed-key check. A first-party field that is only misspelled is therefore never reported as an ffmpeg leak, and an ffmpeg field is never reported as a plain unsupported key. The error names the real problem.

Why the lock exists

Timeline 1.0 is a declarative tool: you describe tracks, clips and timing, and Sume decides how to render and price it. Free-form encoder arguments would make the price and the result unpredictable. Keeping the surface declarative also means the same payload works the same way tomorrow.

// refused: encoder controls
{ "idempotency_key": "cut-9", "payload": { "codec": "libx265", "crf": 18 } }

// error data (shape)
{ "code": "provider_fields_not_accepted", "field": "codec", "next_action": "remove_provider_ffmpeg_fields" }

What to send instead

Remove the key and describe the edit with the fields in the tool schema from tools/list. Read the schema before the first call, not after the error. If your task is a filter such as a crop or a fade, check the dedicated tools; Sume ships separate tools for trimming, filtering and detaching audio, and each takes declarative fields.

Retry with the same idempotency_key, since the refused call created nothing.