Presentation info

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context by enumerating the full scope of what is returned (shapes with ids, tables, charts, notes, transitions, theme, sections), which is what an agent needs since no output schema exists.

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?

Two sentences, front-loaded with the return content and ending with the optional capability. The long comma-separated inventory is dense but each item is substantive rather than 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 carries the burden of describing return content and does so thoroughly. The remaining gap is that it says nothing about the input (input_path) or how results relate to the sibling tools, but for a straightforward read-only inspector this is close to complete.

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 67%, and the description reinforces the 'review' flag ('Optionally a spelling and accessibility review') and the scope of shape enumeration. It does not explain the 'details' toggle or the input_path format, so it adds only marginal meaning beyond the schema's own parameter descriptions.

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?

The description names the resource precisely (slides of a PowerPoint or DeckCraft file) and enumerates exactly what is extracted, so an agent knows this is a read/inspection tool. However, it never explicitly differentiates itself from siblings like get_deckcraft_status or render_slides, so the agent must infer the boundary.

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?

There is no when-to-use guidance, no statement of when an alternative (e.g. render_slides or get_deckcraft_status) is preferable, and no prerequisites. The only usage hint is the word 'Optionally' attached to the review capability, which is really a parameter note rather than routing guidance.

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