Roteiro em lote (várias cenas de vídeo)

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations only covering readOnly/openWorld/destructive, the description carries the real behavioral load: the daily mcp-google cap is checked before sending, only what fits the call window is submitted while the rest is queued, and the total estimated cost is surfaced. It also discloses the fixed output location /app/%LOCALAPPDATA%\mcp-google/saidas/flow regardless of client.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with what the tool does, then queue/polling behavior, then the cost-saving tip, then output location — a sensible priority order with no filler. It is dense but every sentence carries operational information an agent needs; only the model cost table is arguably duplicated from the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description covers the asynchronous contract (partial submit, queue, flow_status loop), the cost preview, the daily-cap precondition, and where files land — everything needed to call and follow up on an open-world, non-read-only tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 80%, so the baseline is already 3; the description adds value by framing cost as 'cenas × custo do modelo' and by constraining max_creditos_total to explicit user requests while noting the daily cap always applies. It does not re-explain the per-scene fields (personagens, referencias, imagem_inicio), which is correct since the schema already documents them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'Gera várias cenas de vídeo de uma vez (até 10)'. The batch framing plus the per-scene fields distinguishes it from the single-video sibling flow_gerar_video without needing to inspect either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit operational routing: call this, then 'Repita flow_status até terminar' to push queued scenes and download finished videos. It also names an alternative workflow (generate stills first with flow_gerar_imagem, 0 créditos, then pass them as imagem_inicio) and states a when-not for max_creditos_total ('só use se o usuário pedir').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.