Gerar apresentação de slides

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

Annotations only declare readOnly=false, openWorld=true, destructive=false; the description adds the behavior that actually matters: the long 4-7 minute duration, the non-blocking partial response on Claude Desktop, the polling escape hatch, and the fixed output directory. It also discloses side effects (files written to disk, including .md text per slide) that the annotations do not capture.

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?

Four sentences, front-loaded with what is generated and then the runtime/async caveat, which is the highest-risk fact. The final path sentence is dense (with an odd %LOCALAPPDATA% fragment) but carries real information; nothing is padding.

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?

With no output schema, the description still tells the agent what comes back (files, not inline content), where they land, how long it takes, and how to retrieve them when the call returns early. That covers everything needed to call the tool correctly and handle its result.

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 description coverage is 100%, so every parameter including notebook, foco, baixar, fontes, idioma, duracao, formato and uso_maximo is already documented in the schema. The description adds no syntax or default detail beyond what is there, so baseline 3 applies.

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?

States a specific verb and resource ('Gera uma apresentação de slides a partir das fontes') and enumerates the artifacts produced (PDF/PPTX/imagens plus per-slide .md). It does not explicitly contrast itself with the many sibling generators (notebook_gerar_audio, _video, _infografico, _relatorio, etc.), so the agent must infer the choice from the resource name alone.

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 concrete operational guidance: ~4-7 min runtime, and a precise branch — on Claude Desktop the reply comes back 'ainda gerando' and you must poll notebook_estudio_status until download, while on Claude Code the call blocks. It does not say when to prefer slides over the other studio artifact tools, but the async routing is explicit and names the correct sibling.

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