Editar imagem no Flow

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

Adds substantial context beyond the annotations: cost (0 créditos em out/2026), non-destructive behavior toward the original image, an automatic PT→EN prompt translation that can corrupt in-image text, and a fixed output directory shared across Claude Code and Claude Desktop. These are exactly the operational surprises an agent needs warned about before calling.

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 the core action and examples before the caveats and the path note. The final sentence about /app/%LOCALAPPDATA%\mcp-google/saidas/flow is dense and slightly awkward, but every sentence carries information an agent would otherwise lack.

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?

For an 8-parameter generative tool with no output schema, the description covers cost, output location, source-image preservation, and translation risk. It stops short of saying what is returned (paths? image ids? one item per variation), which matters given the 'quantidade' parameter, but that is the only notable gap.

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 88%, so the baseline is 3; the description earns an extra point by clarifying that 'imagem' is used as a reference and that 'instrucao' is written in Portuguese and may be machine-translated. Repeating the textual-override syntax for 'instrucao' gives the parameter practical semantics the schema alone doesn't convey.

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?

Specific verb + resource: 'Edita uma imagem existente com Nano Banana', using the source image as reference plus an instruction. The examples ('troque o fundo por uma praia', 'deixe em estilo aquarela') make it immediately distinguishable from flow_gerar_imagem, and the closing note 'Gera uma imagem nova; a original não muda' pins down the operation's nature.

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?

The description supplies concrete usage examples and the transformation scenario the tool is meant for, plus a caveat-driven workaround ('para manter, diga "texto exatamente em português: ..."'). It does not explicitly name flow_gerar_imagem as the alternative for images that don't yet exist, so the boundary is implied rather than stated.

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