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

With no annotations, the description carries the full burden and delivers: 'Does not mutate TS', re-run analyze after any TAL/point change (I-2), dismiss=true hides the entire dock including header bar while keeping stats and sets analysis_panel.dismissed=true, and a thin {tal_analyses} object returns INVALID_REQUEST rather than an empty dock. These are real behavioral traits beyond any structured field.

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?

Front-loaded with a bracketed tier tag and 'When:' clause, then prerequisites and edge cases. Every sentence carries information, but the run-on packing of many clauses into single sentences makes it denser than ideal for scanning.

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?

An output schema exists so return values need not be described, and the description still covers prerequisites, invalid inputs, dismiss lifecycle, dual-surface rendering, and re-run rules. Nothing an agent needs to call this 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?

Schema coverage is 0% across 9 params, so the description must compensate; it explains map_session_id, task_id/job_id, the required full-Analyze shape of analyses, the single|compare|executive|diagnostic values of presentation_mode (and that territory_metric_grid is not one of them), and dismiss. It leaves roles, labels, and guidance_handle unexplained, so it is strong but not complete.

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 names a specific verb+resource (show/load the Analyze JSON analysis panel into the MC bottom dock) and explicitly distinguishes itself from the sibling `analyze` tool by telling the agent to prefer `analyze(analysis_panel=single, ...)` when possible. An agent can identify this as the secondary display-only call without opening any schema.

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?

It states exactly when to use it (after a completed analyze that omitted analysis_panel), the preferred alternative and its parameters, prerequisites (map_session_id plus a full Analyze result via task_id/job_id or analyses), and when NOT to pass analyses (dismiss call). Explicit exclusion and alternative routing are both present.

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