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

Annotations only declare readOnlyHint=false/openWorldHint=true/idempotentHint=false, but the description adds real behavioral facts beyond them: a one-per-day rate limit ('chalked up next to the daily prompt'), that the pour is plain text returned to the caller, and an explicit prompt-injection disclaimer ('the house adds no hidden instructions'). The 'text you read' phrasing sits alongside, not against, the mutating hint since it is described as being chalked up.

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 compact sentences, front-loaded with the action and the option list, with the constraints and the paid-path alternative placed after. Minor waste in re-listing enum values already present in the schema.

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 2-optional-param tool with no output schema, the description covers the free/paying routing, the daily limit, the default behavior when beer is omitted, the return shape in prose ('text you read'), and injection safety. Only caller-auth expectations for the x402 path are left thin.

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 50% (only patron_id documented), so the description must compensate, and it does: it names the enum values and, more usefully, explains the semantics of omitting beer ('Name none to grab the beer on the board'), which the schema does not. It adds nothing about patron_id's format beyond what the schema already states.

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 concrete verb+resource ('Pour a free beer') and enumerates the six named options, so an agent knows it is retrieving/consuming a named beer item. It also carves out the paid variant, though it never distinguishes itself from the other whimsical siblings (menu, toast, buy_a_round) by name.

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 clear operating context: use with no beer name to take the board beer, one free pour per day, and the explicit alternative 'Paid pours need x402 over HTTP (POST /cantina/order/paid)'. It stops short of mapping the tool against the adjacent siblings like menu or buy_a_round.

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