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

Annotations already establish readOnlyHint=true and openWorldHint=false, and the description adds genuinely non-obvious behavior: dual render modes (interactive MCP App view vs. identical JSON payload), the fact that the demo scores the reader with OCS = TPR - FPR on six cases, and the important caveat that rows are historical calculations rather than a ranked leaderboard. That last point pre-empts a likely misinterpretation.

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?

Content-first ordering: what it shows, then the caveat about historical rows, then render-mode behavior. Four sentences and no filler, though the opening sentence is heavily loaded with undefined acronyms, forcing a second read.

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 read-only single-param view tool with no output schema, the description covers what appears on screen and how non-MCP-App hosts behave, which is most of what matters. It stops short of describing the JSON payload shape and does not resolve the boundary with get_operant_results or play_demo, leaving real routing ambiguity.

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% and the single optional enum param is fully documented in-schema, so the baseline is 3. The description names both tab concepts ("calibration-profile cards" and "playable demo"), which loosely maps to the profiles/demo enum, but it adds no format or default information beyond the schema.

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 gives a concrete verb+resource ("Show the public OPERANT benchmark") and enumerates what is rendered: calibration-profile cards, historical OCS repeats, cross-provider TPR/FPR profiles, and a playable demo. An agent can tell it is a presentation tool rather than a data-fetch tool, though the domain jargon (OCS, TPR/FPR) is never unpacked and the overlap with siblings get_operant_results and play_demo is not addressed.

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?

There is no statement of when to pick this over get_operant_results (same data, presumably non-visual) or play_demo (the demo is also bundled here). The only conditional sentence is about host rendering capability ("Hosts that support MCP Apps render it as an interactive view; others get the same data as JSON"), which is runtime behavior, not selection guidance. The agent must infer routing from sibling names alone.

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