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

The annotations already carry readOnly, idempotent, and non-destructive signals, so the safety profile is covered. The description adds genuinely useful behavior beyond annotations: it returns a branded SVG that renders directly in the chat and explains how to highlight a focal entity. There is no contradiction with the annotations.

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 three dense, scannable sentences: purpose, chart-type menu, and output/behavior. Every clause contributes new information — chart variety, SVG return format, chat rendering, and focus highlighting. The chart-type list is slightly redundant with the schema enum but serves quick comprehension before an agent opens the schema.

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?

For a tool with only two parameters, both exhaustively documented in the schema, this description is complete. It discloses the return format (branded SVG), the rendering behavior, and the optional focus usage. Since there is no output schema, stating the return type is especially valuable. Nothing essential for correct invocation is missing.

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 100%: chart_type is fully enumerated and data has per-chart JSON shapes. The description adds a clear, instructive usage rule for the focus mechanism ('top-level "focus":"Name" or per-item "focus":true'), which goes slightly beyond the schema's structural mention. Some redundancy with the enum exists, but the added guidance earns a 4.

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 and object — 'Create a presentation-ready data visualization' — and identifies the source as 'research findings'. It then enumerates six chart types so an agent immediately understands the tool's scope and can distinguish it from the non-visual sibling tools like get_evidence or search_graph.

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 it should be used when a presentation-ready visual chart is requested, but it gives no explicit when-to-use, when-not-to-use, or alternative tool guidance. It does help selection within the tool by listing chart types and their conceptual purpose, but it never says what to prefer over other siblings.

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