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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't bear the full safety burden. The description adds useful context about the output structure and export targets (Google Slides, Notion, Pitch.com), but it does not disclose potential caveats like latency, async behavior, or failure modes. It also includes an irrelevant 'Delivered by Sarah' persona note, which adds noise rather than behavioral insight.

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 description is concise and front-loaded, stating the main action and output first, then usage context. The 'When to use' phrase is helpful, but the sentence 'Delivered by Sarah, the AI Fundraising lead of the Gapup portfolio' is unnecessary fluff that does not help the agent select or invoke the tool. Otherwise, every sentence earns its 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?

The tool has moderate complexity (nested objects, 5 params, output schema), and the description covers its purpose, when to use it, inputs, and output format. Since an output schema exists, detailed return-value explanation is unnecessary. The description is missing mention of the async option, but the schema documents it, so the context is complete enough for an agent to use the tool correctly.

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 high (80%), with detailed descriptions for audience ('adapts tone + emphasis + Q&A bank'), slideCount ('12 = standard VC deck...'), and keyFacts. The description merely restates that inputs are 'the company profile and the target audience type,' adding no new meaning beyond the schema. It does not clarify the 'company' nested object parameters or the 'async' flag, but the schema already covers these, so the baseline 3 is appropriate.

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 opens with a specific verb+resource: 'Build a complete investor pitch-deck storyline for a company.' It further details the slide narrative (8-20 slides, each with title, key points, speaker note, visual hint) and the Q&A bank, making the tool's function unambiguous. While sibling tools like capital_strategy or investor_shortlist are adjacent, none claim to produce a full pitch-deck storyline, so this description clearly distinguishes the tool.

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 explicitly states the trigger condition: 'When to use this tool: the user is preparing a fundraise, a board meeting, or an investor presentation.' This gives clear context for when the tool is appropriate. However, it does not mention when not to use it or suggest alternative tools, so it falls short of a full 5.

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