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

No annotations are provided, so the description carries the burden. It helpfully discloses the return shape (match count, prize, per-bet prize, redemption deadline) which stands in for the missing output schema, but says nothing about whether it is read-only, requires auth, rate limits, or what happens with invalid numbers.

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 bracket category tags followed by one dense sentence that covers input and output; every clause earns its place. Minor overhead from the bracketed tags, but no wasted prose.

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 4-parameter tool with no annotations and no output schema, the description covers outputs reasonably but leaves the period parameter undocumented and omits any behavioral details (safety, auth, error handling). Adequate but with clear gaps.

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 only 25%. The description names game and numbers (the two required params) but gives no format guidance for numbers, and completely omits the period parameter, which has no schema description either. Only 'second' carries its own schema description, so the description fails to compensate for the coverage gap.

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 (對彩券 / check lottery tickets), names the inputs (game, numbers), and enumerates what comes back (matches, prize tier, per-bet prize, redemption deadline). It is clearly distinct from the results-fetching sibling life__get_lottery_results, though it never names that sibling explicitly to draw the contrast.

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 phrase 幫使用者對彩券 implies the use case (verifying your own ticket), but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as life__get_lottery_results for past draw results. Usage must be inferred.

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