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

The annotation readOnlyHint=true already signals a safe read operation, lowering the burden on the description. The description adds value by specifying what is returned (average score, distribution, trend across previous retrospectives), which is behavioral context beyond the annotation. It does not address edge cases like empty boards or data freshness, but that is acceptable for this simple getter.

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 a single sentence that is concise and front-loaded with the action and resource. It includes no filler or redundant information, making every word contribute to understanding the tool's purpose and output.

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 one well-documented parameter and an annotation confirming read-only, the description covers the tool's purpose and the nature of its return values. It does not specify an output schema (none exists) or error conditions, but for a simple read tool, this is sufficiently complete to guide correct usage.

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 provides 100% description coverage for the single parameter board_id, so the description does not need to add extra parameter details. The description adds no new semantics beyond the schema, but the schema itself already clearly explains that board_id is the board identifier. This meets the baseline for high schema coverage.

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 clearly states the tool's function with a specific verb ('Returns') and resource ('ROTI voting metrics for a retrospective board'). It also enumerates the contents (average score, distribution, trend), which distinguishes it from sibling tools like retro.board.health.get or retro.board.summary.get.

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 this is the tool for ROTI metrics but does not explicitly state when to use it over alternatives or mention any exclusions. Given there are sibling tools for board health, summary, and insights, explicit guidance would be helpful, but the unique metric name makes the purpose reasonably clear.

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