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

Annotations declare it is a non-read-only, non-idempotent, open-world write, so the base safety profile is covered. The description adds real value beyond that: ShareHTML sanitizes and validates the deck, persists it, applies access controls and CSP, and returns a viewer URL — plus the visual-QA expectation and the required disclosure when rendering tools are missing.

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?

The opening sentence is well front-loaded, but the middle is a long, comma-chained run-on about rendering, re-rendering, and print-size inspection that could be tightened. Much of it earns its place as procedural guidance, but the density costs readability.

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 five parameters, nested sharing/styleRef objects, no output schema, and no enum hints, the description covers the return value (viewer URL), the sanitization/access-control behavior, and the recipe dependency. It leaves sharing-mode differences and the styleRef read-permission requirement to the schema rather than restating them.

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 80%, so the schema already documents html, title, sharing, styleRef, and presentation. The description adds only marginal semantics (html must follow the recipe; recipeId selection guidance for the preceding get_recipe call) and does not explain the sharing modes or style provenance beyond what the schema says.

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 concrete verb and resource ('Create slides ... as a first-class HTML presentation') and enumerates the artifact genres it targets, so the agent knows this is a deck-publishing tool. It does not, however, distinguish itself from the sibling publish_html/publish_page tools, which is the main differentiation gap.

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 workflow prerequisites: call get_recipe first, with a conditional recipeId choice ('pm-decision-deck' for a PM seeking a product decision, otherwise 'presentation-deck'). It also states the visual-QA obligation and the fallback disclosure when rendering is unavailable. It stops short of naming when to prefer a sibling like publish_html instead.

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