The Odds Gap

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely useful behavioral context beyond that: prices may have moved since the scan and an arb can close at any time, which warns the agent the data is stale and volatile. It does not cover pagination or result limits, but the staleness warning is real added value.

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 short sentences, front-loaded with the definition and ending with the volatility caveat. No filler, though the opening sentence is dense and slightly concept-heavy for a tool description.

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?

An output schema exists, so return-value structure need not be explained, and annotations plus full schema coverage carry the rest. The missing piece is routing guidance against the `middles` sibling; otherwise an agent has enough to call it correctly.

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 100%, so the four parameters are already documented. The phrase 'how a stake would split' loosely reinforces the `stake` parameter, but the description adds no format or constraint detail beyond the schema. Baseline 3 applies.

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 the resource precisely — spots where opposite-side prices sum to under 100% implied — and even describes the output content (stake split). However, it never gives a verb (list/find) and does not differentiate from the sibling `middles`, which is the closest conceptual neighbor for a betting agent.

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?

No when-to-use, when-not-to-use, or alternative naming appears. A reader must infer that this is the tool for arbitrage questions and cannot tell from the text why they would pick it over `middles`, `game_lines`, or `calc`.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, yet the description still adds substantial context: the answer shape, the scan timestamp, a source link, ambiguity handling that returns choices for a follow-up ask, staleness of prices, and the explicit 'places no bets and gives no picks' disclaimer.

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?

One front-loaded paragraph led by the core purpose, then return shape, ambiguity behavior, and safety. Every clause carries information, though the question-type enumeration is dense and slightly long for a single-parameter tool.

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?

An output schema exists so return values needn't be explained, yet the description still covers input style, ambiguity resolution, price staleness, and the no-betting disclaimer. Nothing an agent needs to invoke this correctly is missing.

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% for the single 'question' parameter, including its 400-character limit and inline examples, so the schema does the heavy lifting. The description reinforces 'one whole question ... plain English' but adds no format or syntax detail beyond what the schema already states.

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 ('ask') and resource (a sports betting price question) and enumerates the exact question classes it handles: best price by book, hedge math, parlay price, game board, past result, line movement. That enumeration lets an agent distinguish it from structured siblings like game_lines, calc, or past_game without opening schemas.

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 list of supported question types implies when the tool applies, but it never names a sibling as an alternative or states a when-not condition (e.g., use game_lines for a structured board lookup). Usage is inferable rather than explicit.

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 already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds a genuinely useful constraint beyond structured data: it operates purely on supplied numbers with no market-data fetch, which reinforces the closed-world hint and tells the agent it can rely on self-contained input.

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?

A single front-loaded sentence led by the verb and resource, with the capability enumeration and the self-containment constraint packed into clauses that each earn their place. 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?

An output schema exists, so return values need not be explained, and the single parameter is well covered by the schema. The only minor gap is that input phrasing (how to express odds/prices in freeform text) is not illustrated, which for a broad multi-mode calculator would help an agent form a valid call.

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?

With one parameter at 100% schema coverage, the schema already carries the definition ('The reader's words, with their numbers'). The description's 'numbers you supply' / 'typed odds' / 'typed prices' phrasing adds marginal color but no syntax or format guidance beyond the schema, so baseline 3 applies.

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 ('runs a betting calculation') and enumerates the concrete modes (odds conversion, implied probability, payout, no-vig, hold, breakeven, parlay, arb/hedge). It also distinguishes itself from market-data siblings with 'Uses only the numbers given, no market data,' though the arb/hedge mode hints at overlap with the 'arbs' sibling that isn't addressed.

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 list of calculation modes implies when an agent would reach for this tool, and the 'no market data' clause signals it is for pure computation rather than lookup. However, there is no explicit when-to-use/when-not or named alternative (e.g., arbs vs. this tool's arb split), so routing is left to inference.

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 already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds genuinely useful context beyond them: the value is a snapshot ('the highest price we saw') and it may be stale since the scan. It remains silent on the unusual free-text matching behavior the 'text' parameter implies.

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?

Two sentences, front-loaded with the scope, and the enumerable examples (Super Bowl, World Series, Stanley Cup, NBA, college titles) earn their space by making 'futures' concrete. Slightly list-heavy but no wasted sentences.

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?

An output schema exists, so return shape needn't be described, and the annotations cover safety; the description supplies the one non-obvious trait, snapshot staleness. It is nearly complete, with only the free-text matching semantics left unaddressed.

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 100%, so all four parameters are documented in the schema itself. The description echoes the notions of 'team' and 'market' but adds no syntax, format, or interaction detail beyond what the schema already provides, 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?

States a specific resource (season-long futures) and exactly what is returned: the highest price seen on a team or the top of one futures market, plus a scan time. This clearly separates it from game_lines, player_prop, and slate, but it never names those siblings for 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?

There is no when-to-use guidance and no statement of when to prefer it over game_lines or player_prop. The only contextual note is a staleness caveat ('Prices may have moved since the scan'), which is a warning rather than routing advice.

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 already cover read-only, idempotent, and non-destructive behavior, and the description adds genuinely new context beyond them: the response shows a scan time and a link to the game page, and prices may have moved since the scan. That staleness caveat is exactly the kind of behavioral disclosure annotations cannot convey.

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?

Four short sentences, front-loaded with what the tool returns, and the freshness caveat is placed last where it reads as a qualifier. The naming example ('Lions at Bears') largely duplicates the schema's own example, a minor 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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. The description covers the remaining agent needs: what is returned, the two query modes, the freshness caveat, and how to name the game.

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 meaning beyond the schema by explaining the two modes: both sides on the consensus number versus asking which side the market favors, which clarifies how the line and favored parameters interact.

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 resource and scope: one game's moneyline, spread, or total, with the two output modes (both sides on the consensus number vs. the market's favored side) named directly. It is clearly distinguishable from multi-game or futures siblings, though it never names those siblings explicitly.

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 implies usage (single-game line lookup) and gives input guidance on how to name the game, but never states when to prefer this over slate, futures_odds, player_prop, or past_game, and gives no exclusions or prerequisites.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral caveat beyond the annotations: 'Prices may have moved since the scan,' warning the agent that results are a stale snapshot rather than live odds.

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?

Two compact sentences with no filler; the core purpose comes first and the freshness caveat follows. The colon-heavy phrasing is slightly dense but not wasteful.

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?

An output schema exists, so return values need no explanation, and all three parameters are fully documented in the schema. With annotations covering the read-only safety profile and a freshness caveat supplied, the description is nearly complete; relational guidance versus 'arbs' is the only real gap.

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 100%, so the schema already documents 'game', 'text', and 'books' with usable descriptions. The prose adds nothing about parameter syntax, formats, or defaults, so the 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 states what the tool produces (spread and total middles across sportsbooks) and even defines the domain term inline ('two numbers far enough apart that both bets could win'), so an agent can grasp the concept without outside knowledge. It does not, however, distinguish itself from the closely related sibling 'arbs', which an agent would likely confuse it with.

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?

There is no explicit when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as 'arbs' or 'game_lines'. Usage is only implied by the content of the result.

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 already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful content context about what data the result carries, but says nothing about behavior for the list_all case (single result vs. many) or any freshness/latency characteristics.

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?

A single sentence that leads with the resource and its payload, then closes with the exclusion. No filler and nothing repeated from annotations or 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?

An output schema exists, so return values need no elaboration, and annotations cover safety. The one meaningful gap is the list_all parameter, which switches the tool from a single game to every finished game in the window — a behavioral difference the description's singular framing does not acknowledge.

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 100%, so all three parameters (game, text, list_all) are already documented in the schema; the baseline is 3. The description adds no parameter-level detail, and notably never mentions the list_all mode that changes the shape of the response.

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 names a specific resource (a finished game) and enumerates its payload: final score, closing spread and total, earliest recorded line, and a page link. It clearly bounds scope with 'Never an upcoming game,' which implicitly separates it from siblings like slate and game_lines, though it never names an alternative directly.

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?

'Never an upcoming game' is a genuine negative condition that implies the split with upcoming-game siblings, but no alternative tool is named and no positive trigger ('use this when the reader asks about a game that already happened') is given. Usage is implied rather than stated.

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 already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the board-membership requirement and the staleness caveat ('prices may have moved since the scan') with scan time returned.

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 short sentences with no filler, and the payload summary is front-loaded. The prerequisite and staleness caveats follow in logical order, though the opening sentence is slightly dense.

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?

An output schema exists, so return values need no explanation here. The description covers the key precondition and data-freshness limitation, leaving only minor gaps around failure behavior when a player is off the board.

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 100%, so all five parameters are already documented in the schema, including the market-key example and the books default behavior. The description adds no parameter-level meaning beyond the board-membership note, so the baseline 3 applies.

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 names a specific resource ('one player's prop') and enumerates the payload: the market line, the highest price on each side, and the scan time. It is distinguishable from siblings like game_lines or futures_odds by scope, though it never explicitly contrasts itself with them.

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 states one real precondition ('the player must be on our props board'), which tells the agent when the call will fail. However, it offers no guidance on when to choose this over sibling tools such as game_lines or ask, leaving the selection to inference.

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 already declare read-only, idempotent, non-open-world behavior, so the safety profile is covered. The description adds genuine context beyond that: answers are quoted from the site itself and include a link to the source page, which tells the agent the output is grounded canonical text rather than generated prose.

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?

A single front-loaded sentence that leads with the purpose and folds detail into a parenthetical list. Dense but not padded, and every clause carries information.

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 an output schema present and annotations covering the safety profile, the description need not describe return values. It supplies the domain coverage and provenance needed to invoke the tool correctly, leaving little missing.

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 both parameters are documented structurally. The description does not explain the topic-key-vs-reader-words routing, though its parenthetical list of covered subjects loosely hints at valid lookup areas; this keeps it at the baseline.

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+resource (explains a betting term or site mechanics) and enumerates the content domains it covers, so the agent understands it is an explainer/lookup tool. It does not, however, distinguish itself from the sibling 'ask' tool, which likely also answers questions.

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?

Usage is implied rather than stated: reach for it when a reader needs a betting term or site mechanic explained. There is no explicit when-not, no named alternative (e.g. 'use ask for generated analysis instead'), so the agent must infer the boundary from 'in the site's own words'.

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 already establish readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the data represents the highest observed moneyline per side, includes the scan timestamp, and carries a staleness caveat ("Prices may have moved since the scan").

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?

Two tight sentences with zero filler. The primary capability is front-loaded and the caveat about stale prices follows as supporting context, so nothing is wasted.

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?

An output schema exists, so return-value shape needn't be described, and annotations cover the safety profile. For a six-parameter, zero-required query tool, the description supplies everything an agent needs to choose and call it correctly.

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 100%, so the parameters are already well documented and the baseline is 3. The description echoes a couple of them (window options, league or team) but adds no syntax, defaults, or format detail beyond what the schema states.

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 ("Lists the games in a window") plus the scope options (league or one team) and the distinctive payload (highest moneyline price per side with scan time). This clearly separates it from line-history or results siblings, though it never names a sibling (e.g. game_lines, past_game) to sharpen the boundary.

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?

Usage is implied through the window vocabulary ("tonight, tomorrow, a weekday or a date") and the league/team scope, so an agent can infer the right call context. There is no explicit when-to-use/when-not guidance or named alternative, so an agent comparing against game_lines or past_game gets no routing help.

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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds genuine provenance context ('tracked on The Odds Gap', 'Not an official league record') that the annotations do not convey. It does not discuss ordering, depth of history, or whether the next game may be absent, so it is solid but not rich.

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?

Two short, front-loaded sentences with no filler; the resource is stated first and the provenance caveat second. Nothing is wasted, though the caveat is the only element that adds informational value.

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?

An output schema exists and annotations cover the safety profile, so the description only needs to frame the resource and its data source, which it does. The one gap is that it never clarifies its relationship to sibling tools like past_game, but for a simple single-parameter lookup that is a minor shortfall.

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?

There is a single parameter with 100% schema description coverage ('The team as typed.'), so the schema carries the parameter semantics. The description adds no syntax, format, or matching-behavior detail beyond the schema. 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 names the specific resource (a team's finished games plus its next game) and scopes it to The Odds Gap, which separates it from a generic schedule tool. The implicit verb 'retrieve/list' is not stated outright, but the resource is unambiguous. The caveat 'Not an official league record' further sharpens what data is returned.

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?

There is no statement of when to use this tool versus siblings like past_game, game_lines, or slate, which plausibly overlap for game results. The 'Not an official league record' note is a provenance caveat rather than routing guidance. The agent must infer the use case from the description alone.

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