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

Anticipated score was higher: the description genuinely adds behavior beyond the annotations — server-side sealing before reveal, connection entropy mixed in, a permanent public proof page with a recompute button, an account requirement, and a privacy/publish warning. That is rich context, but the 'sealed' vs. 'published' ordering is stated loosely ('the winner is sealed ... before it is revealed') and no note is given that this is non-repeatable (idempotentHint=false).

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 core action and result-provenance claim, and every sentence carries load-bearing information (proof page, publish warning, account need, frozen_code routing). It is on the long side and the proof-page explanation could be tightened, but nothing 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?

With no output schema, the description carries the return burden and does so well: the result lands on a proof page keyed by a CODE and is openly verifiable. It stops just short of stating the actual response payload fields (winner, code) an agent would receive.

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. The description earns above baseline by disclosing a relationship the schema does not encode: entries and frozen_code are alternatives ('pass frozen_code instead of entries'), plus the public-visibility implication of title and entries.

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?

Names a specific verb+resource (run a certified draw) and the concrete mechanics (server-sealed winner, connection entropy, public proof page). It is clearly distinguishable from spin_wheel, freeze_list and verify_draw, which cover the non-certified, pre-lock and audit paths.

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?

States the selecting condition explicitly ('Use it when the result must be provable to other people') with concrete examples (class prize, team decision, group announcement). It also names the alternative path — pass frozen_code instead of entries — and states an important when-not constraint about publishable names.

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

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

Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context beyond them: the answer varies by authentication state and includes today's remaining certified-draw quota, which is the kind of information an agent needs to interpret the result.

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?

Two sentences, no filler, with the capability summary front-loaded before the trigger conditions. The first sentence is dense but every clause (anonymous mode, account mode, quota) carries information.

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?

There is no output schema, so the description must carry the return-value burden, and it does describe the categories of information returned (capabilities by auth state, remaining certified draws today). It stops short of describing the actual response shape or field names, which for a no-parameter diagnostic tool would be the last missing piece.

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 tool takes zero parameters, so the schema imposes no semantic burden and the baseline is 4. Nothing in the description is needed to explain inputs.

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 uses a specific verb ('Say what ... can do') on a specific resource (this NameWheel connection) and enumerates the two capability modes (anonymous vs. connected account) plus the remaining-certified-draws count. It is easy to distinguish from action siblings like spin_wheel or certified_draw, but it never names a sibling to draw the boundary explicitly.

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?

It gives concrete triggers: 'Use it when the person asks about limits, their account, or why a request was refused.' That is clear when-to-use guidance, covering both proactive and diagnostic cases, but it lists no exclusions or named alternatives for those scenarios.

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

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

Adds substantial context beyond the annotations: entries become immutable ('Nobody can add or remove a name after that'), the title and entries are publicly visible, an account is required, and the frozen page links to the later draw result. These are exactly the auth, privacy, and irreversibility facts the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true) do not convey.

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-loads the core action and the resulting URL, then layers immutability, downstream linkage, trigger, and privacy. Slightly dense and has mild redundancy between 'in public' and 'The title and every entry are public,' but every sentence carries information.

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?

No output schema exists, and the description implies the return (a CODE / frozen_code) rather than stating it outright, which leaves a small gap. It does cover the auth requirement, privacy implications, and downstream usage, so an agent has enough to invoke it correctly.

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%, so both parameters are already documented, including the duplicate-name-slot behavior. The description only reinforces that title and entries are public, adding marginal meaning beyond the schema; baseline 3 is appropriate.

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 and resource ('Lock a list of entries in public before a draw'), plus the concrete artifact it produces (namewheel.org/f/CODE, fingerprint, exact timestamp). It is clearly distinguishable from the sibling certified_draw, which it explicitly references as the downstream consumer.

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?

Gives a clear trigger: 'Use it when entries close before the draw happens,' and explains the relationship to certified_draw (frozen_code) so the agent knows this is the pre-draw step. It does not state an explicit when-not or an alternative tool for other scenarios, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false and idempotentHint=false. The description adds genuinely useful context beyond them: results render as cards in chat, and it 'works without an account', which is auth information the annotations do not carry.

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 core action and output are front-loaded in the first sentence, followed by use cases, parameter rule, and the account note. Five short sentences, no filler, though the account remark could be trimmed.

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 5-parameter tool with no output schema, the description covers the outcome (cards in chat), the two mutually exclusive sizing modes, and the no-account requirement. It omits nothing critical for correct invocation, though error/limit behavior is unaddressed.

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%, so the schema already documents teams, team_size, team_names, title and entries. The description only restates the teams-vs-team_size choice, adding little beyond the schema and no format or limit details.

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 states a specific verb and resource ('Split a list of names into random teams or groups of even size') and adds the output behavior ('show them as cards in the chat'). It is clearly distinguishable from spin_wheel or certified_draw in intent, though it never names those siblings explicitly.

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?

It offers scenario guidance ('class groups, project teams, game sides, rotations') and a parameter rule ('give either how many teams or how many people per team'), which is more than nothing. But it never says when NOT to use it or points to spin_wheel/certified_draw for single-winner draws, leaving sibling selection to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description still adds real context beyond that: the auth precondition, the newest-first ordering, and the fact that each entry carries winners and proof links. It does not mention pagination or behavior at the limit ceiling, but that gap is small against full annotation coverage.

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?

Two tight sentences with no filler; the result scope and ordering are front-loaded and the auth requirement trails as a compact caveat. Every clause carries information an agent can act on.

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 no output schema, the description compensates well by naming the returned fields (winners, proof links) and ordering, and it covers the auth requirement for a two-parameter, zero-required tool. It falls just short of complete because it leaves the relationship between this tool and verify_draw/certified_draw unaddressed.

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%, so both parameters are already documented in the schema (limit default 10, frozen_lists meaning), which sets the baseline at 3. The description's 'or frozen lists' restates the frozen_lists parameter rather than adding syntax, defaults, or interaction rules (e.g. what happens when frozen_lists is combined with limit), so it adds little beyond structured data.

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 and resource ('List this account's recent NameWheel certified draws') plus the payload contents (winners, proof links) and ordering (newest first), so the agent knows exactly what comes back. It does not, however, differentiate itself from adjacent siblings like certified_draw or verify_draw, and the 'or frozen lists' mode partially overlaps freeze_list, leaving the boundary implicit.

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 supplies a prerequisite ('Needs a connected NameWheel account') and reveals the frozen_lists toggle as a mode switch, which implies when each mode applies. It never says when to prefer this tool over verify_draw, certified_draw, or freeze_list, so the routing guidance is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: no account is required, and commas inside a name are transformed into spaces in the link — an input-mangling quirk an agent could not infer from the schema or annotations.

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?

Two sentences, both front-loaded: the deliverable and its use case come first, and the edge-case caveat is a tight trailing clause. No filler or restatement of the title.

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 two-parameter, read-only link generator with fully documented parameters and no output schema, the description covers purpose, use case, auth, and a key input transformation. The only minor gap is that the return shape (a URL string) is implied by 'Make a ... link' rather than stated.

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%, so the baseline is 3, but the description adds real meaning for the 'entries' parameter by explaining that commas in a name become spaces in the generated link. The title parameter's purpose is left to the schema, which handles it adequately.

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 names a specific verb and artifact: it makes a namewheel.org link preloaded with the supplied names, rather than performing a spin itself. That cleanly separates it from spin_wheel, make_teams, or certified_draw, which act on the wheel rather than producing a shareable link.

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?

It states the intended context clearly ('for spinning on a projector, a stream or a shared screen with sound, modes and themes') and adds an eligibility condition ('Works without an account'). It does not explicitly say when to prefer this over spin_wheel or name an alternative, so it stops short of a 5.

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

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

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds substantive context beyond them: no account required, randomness comes from a cryptographic RNG, and the result is explicitly not a certified record. That non-certification caveat is the key behavioral trait an agent needs when choosing between this and certified_draw.

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 the action and outcome, then usage, then the exclusion to certified_draw. No filler and no restatement of the title.

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 no-output-schema, read-only tool this covers everything an agent needs: what it returns (a visible spin result in chat), prerequisites (none), fairness guarantees, and the alternative tool for auditable draws. Remaining mechanics such as winner-repeat behavior live in the schema.

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%, so entries, winners, allow_repeat_winners and title are already fully documented, including repeat-slot semantics and defaults. The description only gestures at 'one or more winners' and 'a list of names or options', adding no syntax or format detail beyond the schema. 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?

States a specific verb+resource+outcome: pick random winners from a list and show the wheel spinning. It distinguishes itself from the sibling certified_draw by name and by the fairness/certification axis, so an agent can route between them without opening schemas.

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?

Explicit when-to-use with concrete scenarios (student to answer, who goes first, where to eat, raffle) plus an explicit when-not: use certified_draw when others must be able to check the result later. It also notes it works without an account, removing a prerequisite question.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description earns additional credit by disclosing the actual verification pipeline (recompute winner, check pre-spin commitment, check Ed25519 signature) and the no-account requirement, though it says nothing about failure modes 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?

It is front-loaded with the core action, then the usage trigger, then the account caveat — each sentence carries distinct information. The opening sentence is dense with verification steps but not redundant; sizing is appropriate for the tool's complexity.

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 only one parameter and no output schema, the description correctly focuses on what is verified and adds a return-relevant fact (it reports how many draws the host ran on this list). It could be slightly more explicit about the shape of the verdict, but an agent has enough to call it correctly.

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 single parameter already documents both accepted forms (8-char code or namewheel.org/v/ link) with length bounds. The description restates that duality but adds no format, error, or normalization detail beyond the schema, 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 description names a specific verb (check/verify) and resource (a NameWheel certified draw), and immediately scopes it to what is being verified: recomputing the winner, checking the commitment, and validating the Ed25519 signature. This is clearly distinguishable from siblings like spin_wheel and certified_draw, which it complements rather than duplicates.

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?

"Use it when someone asks whether a draw or a giveaway result was real" gives a concrete triggering condition, and "Works without an account" clarifies a practical prerequisite. It does not, however, explicitly contrast itself with the sibling certified_draw or exclude near-miss cases, so it stops short of full alternative routing.

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