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

With no annotations, the description carries full burden and exceeds expectations. It discloses return values (two references, EV verdict, Kelly stake), refusal behavior, optional logging with append-only receipt and forecaster_id requirement, the arithmetic nature of the verdict, and legal/research disclaimers. This is rich behavioral context.

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?

Although a single dense paragraph, every sentence adds significant value: usage, input formats, return values, refusals, logging, and disclaimers. It is front-loaded with the critical directive and avoids redundancy.

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 tool's complexity and the presence of an output schema, the description covers virtually all essential aspects: when to use, what it returns, when it refuses, optional logging, and legal caveats. Only the 'sport' parameter is overlooked, but the overall picture is complete for effective selection and invocation.

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 0%, so the description must compensate. It explains event, side, odds_offered with format examples, your_probability as 0-1, and forecaster_id requirement. However, the 'sport' parameter is not mentioned at all, leaving a small gap in otherwise strong parameter guidance.

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 identifies the tool as 'THE pre-bet check' with a specific verb+resource+scope: 'run this BEFORE the user places any bet, on any bookmaker.' It explains what it returns (EV verdict, references, refusal) and distinguishes itself from siblings like compare_platforms and get_market_odds by focusing on a specific bet check.

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?

Provides explicit when-to-use guidance: 'run this BEFORE the user places any bet, on any bookmaker.' It also specifies required inputs (event, side, odds) and optional inputs. However, it does not explicitly mention alternatives or when not to use it, though the strong directive makes the context clear.

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