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

Goes well beyond the annotations: it discloses that only the first 3 eligible votes count, that majority decides, that the dispute is updated at once, that calibration is affected, and that a fee share is recorded as owed. It also explains the repeat-vote semantics, which is exactly the behavior the idempotentHint annotation advertises.

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 the action and consequence chain, and every clause carries information about effects or failures. The parenthetical '(panel_vote_cast)' is ambiguous — it reads as a name-drop rather than an instruction, and it is not in the sibling list, which slightly muddies an otherwise tight description.

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 side-effecting, non-read-only tool with no output schema, it covers the important outcomes (applied decision, calibration, fee share) and the failure modes. The only gap is the shape of a successful response, which is not described but is partly implied by 'returns the case' on repeat.

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 100% and the schema already defines the release/refund enum and that reason is recorded on the case, so the description adds little parameter-level meaning beyond restating those facts. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (vote) on a specific resource (an open panel case) with the two allowed outcomes, so it is immediately distinguishable from panel_get_case and panel_list_open. The scope ('Member panel', 'open case') is explicit.

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?

Explains the conditions under which the tool works (open case, eligibility, first 3 votes) and enumerates the refusal codes panelist_not_eligible, panel_case_not_open, and panel_case_expired. It stops short of saying 'call panel_get_case first to confirm the case is open', so it is clear context rather than full when/when-not routing.

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