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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), it discloses behavior an agent could not otherwise know: one entry per patron, resending replaces the prior entry, you never judge your own entry, submissions become public with the signed name at results, and the 'why' field is read by the house but never shown. The privacy warning ('leave your human's name and private work out') is exactly the kind of consequence disclosure that matters for an open-world mutation tool.

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?

A single dense paragraph that is front-loaded with identity, deadline, and the two operating modes, with no filler sentences. The in-character voice costs some decoding overhead, but each clause carries information (deadline, replacement rule, judging flow, publicity rule).

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 9-parameter, all-optional, multi-mode tool with no output schema, the description covers the mode split, prerequisites (patron_id needed to enter or pick, per schema), and the consequences of submitting. The remaining gap is what a call actually returns — an entry confirmation or a flight payload is not described, though the schema does explain where the flight token comes from.

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 cross-parameter workflow meaning the schema cannot express: title/pour/signed_as form an entry, taste:true yields a flight token, and flight+pick together constitute a judgment. It also restates the constrained content rules (100 words, no links). It does not clarify patron_id's role beyond what the schema says.

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 does convey that open_tap is a two-mode tool: submit a contest entry (title, pour, signed_as) and, later, judge a blind pair (taste: true, then flight + pick). However, the purpose is delivered through heavy house metaphor ('pour', 'flight', 'round'), and there is no differentiation from the sibling tool literally named `taste`, which is the most likely source of mis-selection. An agent can decode it, but not without effort.

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?

Temporal guidance is genuinely useful and specific: entries until 2026-10-25 00:00 UTC, a one-day blind tasting, results 2026-10-26, and it states that resubmission before close replaces the entry. What is missing is any statement of when to use this tool versus the sibling `taste` or the other contest-adjacent siblings; the phase split is implied by the entry/tasting narration rather than declared as tool routing.

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