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

Annotations already establish a safe, idempotent, closed-world read. The description adds genuinely useful behavior the annotations cannot: matching is by trailing digits, coverage spans every jurisdiction and turno, and no side effects like bets or prize calculation occur. The output-presentation rule (don't repeat the widget's numbers, answer in one or two sentences) is extra context the agent could not infer.

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 trigger condition, then scope, then exclusions, then output formatting. The embedded user utterances and the widget-formatting sentence are both load-bearing, though the description is longer than strictly necessary for such a small 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?

There is no output schema, but the description explains the return shape ('lists where it came out'), the matching rule, and the date default is handled in the schema. It is complete enough to call correctly; only minor gaps remain around result granularity (per-jurisdiction list vs. summary).

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 real semantics: 'matched by its last digits' explains matching behavior the schema pattern does not, and the 'a la cabeza or within the first 5, 10 or 20 positions' phrasing clarifies the positions parameter's meaning beyond the enum constants.

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 precise verb and resource ('checks a number of 1 to 4 digits... against every jurisdiction and turno') and anchors it with real user phrasings ('¿salió el 23?', 'controlar quiniela'). This is clearly distinguishable from siblings like get_results or get_cabezas, which enumerate draws rather than validating a played number.

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 explicit when-to-use triggers via quoted user utterances and a clear when-not ('does not calculate prizes or take bets'), plus guidance on how to answer when a widget is shown. It never names an alternative sibling tool, so the routing guidance stops short of tier 5.

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