Create a presentation

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the write-not-read profile is covered. The description adds genuinely new context by disclosing the written artifact set (pptx/pdf/deckcraft/png/jpeg/outline) and that it returns preview pictures of the first slides, but it says nothing about overwriting existing files, where output lands, or failure modes.

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?

Purpose is front-loaded, but the body is a single semicolon-chained run-on sentence enumerating nearly every feature and format, which is dense and hard to scan. Much of the enumeration duplicates what the schema already states, so those clauses do not fully earn their place.

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?

There is no output schema, so the description does well to name the produced formats and the returned preview images. However, for a 20-parameter creation tool it omits practical essentials such as needing absolute output paths for new files and what happens when overwrite is false, leaving real gaps.

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 90% and every one of the 20 parameters is documented inline, so the schema carries the load. The description only echoes the feature categories at a high level (theme, colour and font schemes, slide size, slide numbers and footer, speaker notes, transition and bullet animation) without adding syntax or default details beyond the schema.

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 concrete verb+resource ('Build a slide deck with DeckCraft') and enumerates both accepted input modes (a list of slides or a plain-text outline) plus the output formats. It is unambiguous what the tool does, but it never distinguishes itself from siblings like edit_presentation or convert_presentation, so an agent must infer this is the creation path.

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?

Usage is only implied: the tool is for building a deck from scratch, with 'outline' offered as an alternative to the slides array. There is no explicit when-to-use/when-not guidance and no reference to the sibling tools an agent should prefer for editing an existing deck or converting formats.

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