bet-checker

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

Annotations only indicate readOnly=false, openWorld=true, destructive=false. The description adds extensive behavioral context: only 'graded' spends a check, all possible statuses are enumerated, ungraded_legs.reason and retry.rephrasing_helps are explained, sports coverage is listed, and started games still grade against pre-game projections flagged as such. No contradiction with annotations.

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 long but densely informative. Every sentence earns its place: purpose, usage boundary, alternative tool, statuses, retry semantics, sport coverage, and edge cases. It is well-structured with clear labels and backticked status names.

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 tool with one parameter and no output schema, the description is remarkably complete. It covers invocation intent, all possible statuses, leg-level failure reasons, retry guidance, sport exclusions, and behavior for already-started games. An agent has everything needed to decide when and how to call it.

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?

The schema already describes the single 'bet' parameter with an example, so baseline is 3. The description adds meaningful semantics: input as plain text with teams/players, market, line, odds; multi-leg parlays in one string graded leg by leg; and notes that re-wording won't change a parsed ungraded bet. This goes beyond schema.

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 uses a specific verb 'Grade' and clearly identifies the resource: a sports bet against NegativeEV's game simulations. It also distinguishes itself from siblings by explicitly stating it prices a bet you name rather than searching for good bets, contrasting with get_slate.

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 gives explicit when-to-use guidance: 'Use it when the caller has a SPECIFIC bet to evaluate' and tells what not to send ('what should I bet tonight'). It also directs callers to invoke get_slate first when slate coverage is uncertain and warns against rephrasing to bypass ungraded results.

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

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

Annotations declare readOnlyHint=true, and the description adds meaningful context beyond that: it is 'Free — spends no check,' it is a real-time 'right now' check, and it clarifies the meaning of an 'ungraded' result. This substantially helps the agent predict behavior without contradicting the annotation.

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?

Three sentences, front-loaded with the core purpose, and each sentence adds distinct value: what it checks, how to use the parameter, and when/why to call it. No filler or 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?

With no output schema, the description adequately conveys the return concept ('whether there is a checkable slate... in each live sport') and covers cost, timing, and relationship to check_bet. For a simple optional-parameter status tool, this is complete.

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?

The input schema already provides 100% coverage of the single optional `sport` parameter, including enums and omit behavior. The description reinforces this ('Pass sport to ask about one; omit it for all of them') but does not add new semantic beyond the schema, so baseline 3 is appropriate.

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 uses a specific verb ('whether there is') and names the exact resource (checkable slate in MLB, WNBA, PGA, ATP). It distinguishes itself from sibling tools by explicitly calling this the 'free pre-check for check_bet,' making its role clear.

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?

It provides explicit when-to-use and when-not-to-use guidance: 'call it before grading when it isn't known that today's games are simulated' and 'call it after an ungraded result instead of re-wording the bet.' It also names the alternative (check_bet) and explains why, which is exemplary.

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

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

The readOnlyHint annotation already indicates a non-destructive read operation. The description adds valuable context beyond that: it is free (spends no check), and it distinguishes anonymous callers (daily allowance) from accounts (hourly pace window). This enriches the agent's understanding of quota behavior.

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-loaded with the core purpose, and every sentence adds value. It efficiently covers what, when, and why without redundancy or fluff.

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?

Despite having no output schema, the description clearly states what information is returned (number of checks remaining and timing of next free check) and covers the relevant quota variations. It is complete for this simple, read-only tool.

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?

The tool has zero parameters, so the schema provides no parameter constraints. The baseline for 0 params is 4, and the description appropriately explains what the tool reports rather than focusing on parameters. It effectively communicates the tool's input-independent nature.

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 what the tool does: it reports how many bet checks remain and when the next one frees up. It distinguishes itself from siblings by explicitly stating that `check_bet` spends the quota, while `get_usage` only reports it.

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 explicit when-to-use guidance: call it before grading several bets to know how many will fit, and after a check is refused for quota to know when to retry. It also clarifies the alternative: `check_bet` is the tool that actually consumes checks, so `get_usage` is informational.

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