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

Annotations already cover the safety profile (readOnly, non-destructive, open-world, non-idempotent), so the description's added value is the rendering behavior: it discloses that output is composed of three distinct rendered artifacts and that engine-specific dashboards are auto-selected (e.g. price intelligence for google_flights). It does not mention latency, token/size cost of the richer output, or fallback behavior when a dashboard is unavailable.

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?

Four tight sentences, front-loaded with the tool's identity and return shape, then the alternate-tool relation, then the engine-selection nuance. No filler or restatement of the title.

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 no output schema, the description usefully explains what the caller receives, and the input side is handled by cross-reference to `search`. Minor gaps remain around cost/size of the richer payload and behavior when no engine-specific dashboard exists, but nothing essential to invoking it correctly 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?

The schema has a single free-form `params` object with 0% description coverage, so the description must carry the load — and 'Same params as `search`' is a meaningful delegation that tells the agent where to find the real contract. It still does not enumerate any parameter names or note whether dashboard-specific keys exist, so an agent must consult `search` before calling.

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 and resource ('Interactive dashboard variant of `search`') and immediately enumerates the return composition: summary metrics, source breakdown chart, and results table with a detail panel. This is clearly distinguishable from the siblings `search` (plain results) and `search_table` (table only).

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 a clear selection cue — 'Use for a richer visual overview of a query's results' — and anchors itself to `search` by inheriting its parameters. It does not explicitly state when NOT to use it (e.g. cost/latency tradeoffs vs. plain `search`), leaving the agent to infer the exclusion.

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