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

The description explicitly states that expired promos are excluded, and that the headline percentage is a marketing metric while the decoded terms matter. It also reveals the tool decodes T&Cs. With no annotations provided, the description carries full burden and reasonably discloses key behavioral traits. A slight deduction for not mentioning if the list is sorted or if there are 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?

The description is three sentences long, front-loads the core purpose, and each sentence adds distinct value: what the tool returns, what to use it for, and example calls. No wasted words.

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?

Given the simple tool (2 optional parameters, no output schema, no annotations), the description is nearly complete. It explains what the tool returns, what it excludes, and provides usage examples. It could be slightly more complete by mentioning the default sort order or whether the result is limited by default, but it's adequate.

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 50% — the description does not explicitly detail the 'limit' parameter's meaning, but the schema already defines it with default, min, max. The 'casino' parameter is described in the schema as 'Optional: only bonuses from this casino'. The real world example calls in the description add value by showing typical usage patterns. The description compensates well for missing parameter 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 clearly states the tool returns current best crypto casino bonuses with decoded fine print from T&Cs. It explicitly lists decoded fields (wagering requirement, max bonus, max cashout, free spins, min deposit, real-value score) and distinguishes from the headline marketing percentage. This is a specific verb+resource with clear scope.

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 provides example queries like 'best crypto casino bonus' and 'deposit match with low wagering', and an example call with {'limit': 5} or {'casino': 'BetUS'}. However, it does not explicitly state when NOT to use this tool or compare it to siblings like compare_casinos or top_casinos, which would help clarify differentiation.

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