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

Annotations already cover the safety profile (readOnlyHint, destructiveHint, openWorldHint), so the bar is lower. The description adds genuinely useful behavioral context beyond annotations: the data is synthetic/illustrative (not real client or live measurement), and visual series may be trimmed for the response-size budget. These are non-obvious traits an agent should know before relying on output.

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?

Three tight sentences, front-loaded with what the tool returns. No filler; each clause (synthetic data caveat, trimming behavior) 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?

Output schema exists, so return-value explanation is not needed. The description covers the two required parameters semantically and discloses the synthetic-data and response-trimming behaviors, which are the main things an agent needs. It stops short of usage routing, its only real gap.

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 0%, but both parameters have enum constraints and the description names their semantic roles ('outcome and audience seat'). However, it doesn't explain what each enum value means or which situation maps to which seat, so the parameters remain only partly illuminated.

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+resource: retrieving a 'committed situation-demo export' keyed by outcome and audience seat. This is a targeted lookup distinct from the sibling get_* tools (book, evidence source, guide, outcome model), though it doesn't explicitly differentiate itself from them by noting what makes a situation demo unique versus those artifacts.

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 implies usage (fetch a pre-built demo for a given situation/seat) but offers no explicit when-to-use guidance, no alternatives, and no exclusions. With 11 sibling get_*/list_* tools, some routing context would have been valuable but is absent.

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