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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so there is little safety burden left; the description still adds real context beyond them, notably the 503 error semantics ('voicebot not (yet) in the call') and the meaning of derived fields like 'mine' (asked by this session or one of its helpers) and 'auto'. It does not mention pagination or rate limits.

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?

Purpose and scope are front-loaded in the first clauses, which is good, but the bulk of the text is a long enumeration of returned fields (id, number, question, options, recommend, agent, from, sender, state, at, age_s, mine, context, verdict, option, text, by, decided_age_s) that largely restates the output schema. Much of that verbosity does not earn its place given an output schema exists.

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?

Because an output schema exists, the return-shape prose is not strictly needed, and the remaining essentials — scope, ordering across the three result groups, and the 503 failure mode — are all present. Coverage is solid; only explicit usage routing against siblings 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?

With a single parameter at 100% schema description coverage, the schema already explains that session is 'the `session` value returned by join'. The description adds nothing about the parameter itself, so the baseline 3 applies.

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 opening clause gives a specific verb and resource with scope: 'Lists every OPEN decision on the call's Decision Board, from all agents in the call and their helper sessions' plus ordering ('oldest number first'). It also clarifies the audiences (main agent, helper sessions). It stops short of naming a sibling it is distinct from, so it falls one notch below a 5.

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?

Usage is only implied by the phrase 'read-only overview for the main agent' and by the read-only annotations; there is no explicit when-to-use statement, no condition selecting it over decide/helper_decide/status, and no exclusions. An agent can infer it is the read path, but nothing is stated.

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