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

Annotations cover only the generic profile (not read-only, not destructive, not idempotent, closed-world); the description supplies the domain-specific behavior that matters: no charge, no voter contact, and the four things the response carries back (id, publishing blockers, exact price, finish link). That is real context beyond the structured fields.

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?

Four sentences, front-loaded with what the tool creates, then what it costs/costs nobody, then what it returns, then the elicitation rule. Nothing is repeated from the schema and no sentence is filler.

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 15-parameter, nested, no-output-schema mutation tool, the description is complete: it states side effects (no charge, no contact), enumerates the return payload, and warns that the data supplied is binding. An agent has everything needed to invoke it responsibly.

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%, so the baseline is 3, but the description adds semantic framing the schema does not: it groups the fifteen fields into ballot/schedule/verification/secrecy/results/quorum/roster and singles out the values the agent must elicit from the person (closing date and time zone, seats, candidates). It stops short of explaining individual field semantics like the results enum or verification tiers, which live in 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?

States a specific verb+resource ('Create a DRAFT election') and enumerates the exact surfaces it configures (ballot, schedule, verification, secrecy, results visibility, quorum, state-law checks, voter list). The emphasis on DRAFT also separates it from publish_election and list_elections.

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 context is clear: a draft charges nothing and contacts nobody, so an agent knows this is the safe pre-publish step, and the closing instruction ('ask the person for anything you do not know') rules out guessing. It stops short of naming siblings explicitly, leaving the agent to infer create_election_draft vs. start_election_draft, which is the one ambiguity that matters here.

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