StrikerAPI

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 new behavioral context: results are ordered, historical matches have reduced coverage, and each call costs 10 credits — the cost disclosure is exactly the kind of thing annotations cannot express.

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 with purpose, then filtering, then the coverage caveat, then cost — a sensible information order in three tight sentences. The long enumeration of event fields is dense but earns its place by previewing the payload.

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 explanation is rightly omitted; the description instead covers ordering, historical coverage limits, and credit cost for a 5-param read tool. The only real gap is the mismatch between described event types (corners, offsides) and the kind enum values, which could mislead filtering.

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 enum and defaults for kind, limit, league and offset are already documented; the description's "Filter with kind" adds little beyond that. Worse, it lists "corners, offsides" as event types while the kind enum only offers set_pieces/fouls/goals/shots/cards/substitutions/all, so an agent could infer a non-existent filter value.

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?

Opens with a specific verb+resource and scope: "Use for a match's events in order," then enumerates exactly which event types are returned (goals with assister/own goals/penalties, shots with location/outcome/body part/xG, cards, subs, fouls, corners, offsides, VAR). An agent can tell this is the match-event feed rather than a stats or shot-map tool, though no sibling is named 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?

"Use for a match's events" plus "Filter with kind" gives clear context for when this applies, and the older-match caveat ("Older matches carry goals, cards and substitutions only") tells the agent when results will be thin. It stops short of naming alternatives (e.g., get_shot_map for shot visualizations) or stating exclusions.

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-destructive, closed-world behavior, so the bar is lower. The description still adds real context: the 5-credit price and the pricing-information policy constraints, which are not derivable from annotations or schema.

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-loads what the tool returns, then immediately routes to alternatives, then states cost and policy. Every clause carries new information; there is no filler or repetition.

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 100% parameter coverage, the description needs only to explain scope, alternatives, cost, and constraints, and it does all four. Nothing necessary for correct invocation 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 description coverage is 100%: game_id is documented as coming from list_games or get_schedule, and league carries its full enum and default. The description adds no parameter-level detail beyond that, 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?

States a specific verb and resource ('one match in full') and enumerates the exact payload: score with shootout, box scores with named metrics, player lines, key events, and opening/closing lines. It explicitly distinguishes itself from siblings get_events and get_lineups, so an agent can select it without opening the schema.

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?

Gives explicit routing rules: events go to get_events, formations to get_lineups. It also states the 5-credit cost and the compliance boundaries (no stake/payout/profit calculation, no bet recommendations, no sportsbook referrals), which are usage conditions an agent must know before calling.

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 a closed-world scope, so safety is covered. The description adds information annotations do not carry: a concrete cost of 2 credits, plus the fact that results are returned newest-first and include the first meeting. It does not mention rate limits or auth, which keeps it below a 5.

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 front-loads the triggering scenario and then lists the returned content, with no filler. The credit cost is appended compactly at the end where it is easy to scan.

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, the description needn't explain return values, yet it usefully flags the newest-first ordering and the credit cost. Combined with 100% schema coverage and rich read-only annotations, an agent has what it needs to call this correctly. Only the lack of sibling disambiguation keeps it from a 5.

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 team, opponent, league and limit are already documented in the schema, including the note that the summary counts every meeting regardless of limit. The description only reinforces the two-club framing and the league scoping ("this competition") without adding format or identifier guidance. 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 a specific resource (two clubs' head-to-head meetings in a competition) and enumerates what the result contains: wins, draws, goals each, first meeting, newest-first ordering. That is far more specific than the name alone. It stops short of distinguishing itself from siblings such as get_game or get_team_stats, but the purpose is unambiguous.

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?

"Use for two clubs' meetings in this competition" is a positive usage directive, so the agent knows the triggering scenario. However, there is no statement of when to prefer get_game, get_events or get_team_stats instead, and no prerequisites or exclusions. Usage is implied by scenario rather than explicitly routed.

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, so the safety profile is covered. The description adds two things the annotations cannot: a 5-credit cost and the default 10-match floor for per-90 ranking, both material to invocation and result set size.

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 front-load the use case, then the cost. Nothing is repeated and no filler is present.

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, return values need no explanation; the description covers stat scope, per-90 behavior, defaults and cost. It does not mention result ordering (implicitly descending) or a default for limit across all five optional parameters, which is a minor residual gap for a 6-parameter 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?

Schema coverage is 83% (high), so baseline is 3; the description exceeds it by disclosing that min_games defaults to 10 for per90 mode, a default the schema does not state. The stat enum and per90 toggle are only restated, and limit/league/season are left to the 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 states a specific resource (a season's statistical leaders) and enumerates the exact stat categories covered, including the totals vs per-90 mode. It does not name a differentiating sibling (get_standings, get_team_stats) but its scope is nonetheless unmistakable from the stat enumeration.

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?

"Use for a season's leaders in..." gives a clear selection context, and the parenthetical explains the per90 variant including its default minimum-games threshold. No when-not-to-use case or named alternative is given, which keeps it out of the 5 tier.

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 this as a safe idempotent read, so the description correctly focuses on what they cannot express: the snapshot cadence (daily, hourly for matches within four days), the 10-credit cost, and a hard compliance boundary against staking or betting advice. These are exactly the operational facts an agent needs before calling a priced data endpoint.

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 plus a short constraint clause, roughly fifty words, with the purpose front-loaded and the cost and compliance facts placed where they will be read before invocation. Nothing is redundant.

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 structure need not be explained; the description instead supplies the parts the schema cannot: cost, capture frequency, and the missing-data caveat that identical consecutive captures are collapsed. For a read-only historical endpoint 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?

Schema description coverage is 100% and each parameter is already documented, including the dedup behavior of all_snapshots, so the schema carries the load. The description's cadence detail indirectly clarifies why all_snapshots exists, but it adds no explicit guidance on league/provider selection or game_id format. 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 verb and resource ('see how a match's line moved before kick-off') and enumerates exactly what is returned: pre-game snapshots of three-way moneyline, handicap and total per sportsbook. This clearly separates it from get_odds (current prices) and get_prop_history (player props) without the agent needing to open any schema.

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 opening 'Use to see how a match's line moved before kick-off' sets the usage context well, and the trailing prohibition ('never work out a stake, payout or profit, recommend a bet, or send the user to a sportsbook') is an explicit when-not-to-use constraint. It stops short of naming a sibling alternative for current prices (e.g. get_odds), so it is clear but not fully contrastive.

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 description adds substantial behavioral detail beyond the read-only annotations: it discloses the 5-credit cost, the club-confirmed live source, the pre-match timing window, and that nothing is charged when lineups are empty. This is exactly the kind of operational context an agent needs before invoking the tool.

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 front-loaded with the resource and returned contents, then moves to timing and cost without wasted sentences. Every sentence adds useful information for invocation.

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 full parameter coverage, the description still supplies the key operational facts: what is returned, when it is available, what happens before publication, and the credit cost. Nothing essential for correct invocation 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 description coverage is 100%, so both game_id and league are fully documented in the schema. The description mentions the match context implicitly but does not add meaning beyond the schema for either parameter.

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 resource and its specific contents: each club's formation, starting XI, substitutes, and unused bench. It is unambiguous against siblings like get_game or get_events, though it does not explicitly name an alternative tool.

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 clear context for when to use the tool, including pre-kick-off behavior from about an hour before the match and the empty response before clubs publish. It does not state when to use a different sibling tool instead.

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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses billing behavior (10 credits per call, refund when no lines exist), capture semantics (opening is first captured line, closing is last before start, minutes_before_start can be negative), and coverage limits by league and date. It also adds usage constraints about not computing stakes or recommending bets, which annotations alone do not 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?

The description is front-loaded with purpose and usage, then moves into return shape, coverage limits, pricing and policy constraints. It is long but every sentence carries operational value; the main market list is slightly redundant with the schema enum, which keeps it from a 5.

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?

Even though an output schema exists, the description explains what the returned opening and closing lines contain (outcomes with point and American price, captured_at, minutes_before_start) and warns that opening and closing often match because most books were captured once. Combined with the pricing, coverage and policy notes, an agent has everything needed to call it correctly and interpret the result.

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 schema already documents each parameter. The description still adds meaning by naming the sources for game_id and mapping market names to their concepts (e.g., draw no bet voids on a draw), and it explains the practical effect of estimate_only. Bookmaker semantics are left entirely to the schema, keeping this just short of a 5.

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 (extra betting markets as history) and enumerates the markets covered: both teams to score, draw no bet, double chance, and 1st half result/total/handicap. It explicitly distinguishes itself from get_odds, which handles full-game moneyline, spread and total, so an agent can route correctly without opening either schema.

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 when to use this tool (extra markets as history), where game_id comes from (get_schedule or list_games), and names the alternative for other markets (get_odds for full-game moneyline, spread and total). It also flags estimate_only for price checks and the 10-credit cost with refunds for games with no lines, giving the agent enough to decide whether to call.

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 covered. The description does add real context beyond them: credit costs per call mode, the historical coverage boundary (June 2020 for 16 competitions, 2024 for the rest, single final line before that), and pagination bounds. However, the credit figure quoted for game_id and the 2-credits-per-match for season sit awkwardly with the 10-credit figure for date without explaining whether they combine, and nothing is said about ordering or failure modes; with annotations carrying safety, a 3 reflects solid but incomplete added context. Note that the schema's 17-league enum sits against the description's "16 competitions", a minor inconsistency.

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 with the resource and its payload before the mode/cost instructions, and every clause carries information. The opening sentence is extremely long and stacks six distinct concepts, which costs some scannability.

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, yet the description still tells the agent what fields matter (lines, implied probabilities, over/under result vs median close). Coverage limits, credit costs, page size and the responsible-use restriction are all present, leaving nothing essential missing for correct 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 coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: cost per call mode, that limit/offset apply only in season mode with up to 100 per page, and that team is used with season. It does not clarify how the three query modes interact if several are supplied, leaving one semantic 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+resource ("betting lines") and then enumerates exactly what is returned: three-way moneyline, goal handicap, total with opening/closing, implied no-margin probabilities, and settled results. That enumeration separates it from siblings such as get_player_props (player-level props) and get_line_movement (price changes over time) without either schema being opened.

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?

Gives concrete routing guidance: game_id for one match, date for a day's slate, season (optionally with team) for a season of priced matches, each with its credit cost. It does not name an alternative tool or state when to use a sibling instead, so it stops short of full when/when-not guidance.

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, so the safety profile is covered. The description adds genuinely new context: a concrete cost of 5 credits and the exact scope of the payload including per-90 rates and the last 10 matches, which tells the agent this is a heavy/expensive call worth caching.

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 dense sentence that front-loads the use case and then packs in the field inventory and credit cost with no filler. The long enumeration is justified because it tells the agent what data it avoids fetching separately.

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 safety, the description only needs to sell scope and cost, which it does. The one real gap is the absence of any pointer to get_player_games for broader match logs, given this tool already returns the last 10 matches.

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%, with both parameters documented and the league enum fully enumerated in the schema, so the baseline is 3. The description adds nothing about the parameters themselves, though 'one player' reinforces that player_id is a single ID rather than a list.

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 ('use for one player') and enumerates the returned data categories in detail, so the agent knows exactly what this fetches. It stops short of naming the overlapping sibling get_player_games, which also surfaces match-level data, leaving some ambiguity about which to pick for game logs.

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?

'Use for one player' implies the single-entity lookup case, and the player_id schema field points at search_players for ID resolution. But the description gives no explicit when-not guidance and never acknowledges get_player_games or get_player_props as alternatives for adjacent data.

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/openWorld=false, so the safety profile is covered. The description adds genuinely new context the annotations don't carry: result ordering (newest first) and a concrete cost of 5 credits, which is decision-relevant for an agent. It omits pagination/result-count behavior, keeping it at 4.

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, front-loaded with the use case, then the output content, then cost. Every clause carries information and nothing is padded.

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 the field list is arguably redundant, but the description never addresses paging (limit max 200, offset) or how league/season narrow the log — gaps that matter for a 5-parameter list tool. Adequate but not 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?

Schema coverage is 60%: league, season and player_id are described, but limit and offset have no descriptions anywhere. The description mentions no parameter at all, so it does nothing to close the gap on the two undocumented paging parameters.

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 ('a player's match log') with scope (per player), ordering (newest first) and the fields returned. An agent can distinguish it from get_game (single game), get_player (profile) and list_games (game list) without opening a schema.

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 'Use for a player's match log' opener gives a clear usage trigger and the newest-first ordering signals the right context for recent form. It never names an alternative or an exclusion (e.g., when to prefer get_game for a single fixture), so it stays below a 5.

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?

Beyond the annotations, it discloses credit costs, account-specific pricing, the free estimate mode, default closing-line behavior, capture timing and row-retention rules, and the NFL/NBA start-time nuance. This is exactly the kind of behavioral context that helps an agent invoke the tool correctly.

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 front-loaded with its purpose and is dense with useful detail rather than padding. It is long, but the complexity of costs, capture timing, and query modes justifies most of the length; stronger paragraph structure would improve readability.

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?

It covers selection between game-level and player-level queries, charging behavior, snapshot defaults, data-retention nuances, and compliance constraints. With an output schema and full annotations already present, the remaining description is complete for an agent to call this tool 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 coverage is 100%, so the baseline is 3, but the description adds meaningful semantics for game_id, player_id with date ranges, the 100-row cap, snapshot_type defaults, and estimate_only. It adds less detail for league, market, and bookmaker, but those are already well covered by the 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 states a specific resource and operation: player prop lines by sportsbook, for the anytime goalscorer market, with named books. It cleanly distinguishes this from broader odds or history tools by specifying the exact prop market and the game/player query modes.

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 gives clear invocation modes: use game_id for every player's props in one game, or player_id with from_date/to_date for one player across games, and it explains estimate_only. It does not explicitly name when not to use this tool or compare it directly against siblings such as get_odds or get_prop_history.

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?

Goes well beyond the readOnly/idempotent annotations: it discloses a precise cost model (10 credits per 25 games played, minimum 10 per call, legacy-account pricing), a free dry-run via estimate_only, the 200-game cap per call, and the null/void semantics when a player was not in the squad or on the pitch. It also states the market-information policy (no staking, payout, or bet-recommendation output), which is behavioral context an agent cannot infer from any structured field.

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?

Purpose is front-loaded and nearly every clause carries information the agent needs (row grain, cost, void rules, policy). The cost is a very long run-on sentence dense with parentheticals, which hurts scannability; splitting pricing and row-semantics into separate sentences would read better.

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 an 8-parameter, paid, read-only history tool with an output schema, the description covers the non-obvious pieces an agent must know before calling: charge amount and how to avoid it, the per-call game cap, how void results appear, and the prohibition on betting advice. Nothing needed to invoke it correctly or to interpret the response 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%, so the baseline is 3; the description still adds real meaning on top by defining over_odds as the Yes price, explaining that the opening line equals the close where only one capture exists, and clarifying that the closing line is the median across books unless bookmaker narrows it. It does not re-explain from_date/to_date or limit, which the schema already documents well.

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 opening clause states a specific verb and resource: see how a player did against his prop line over time, and immediately defines the row grain (one row per game) and the fields returned (closing line, opening line, prices, box-score result, over rate). It is clearly distinct from the sibling get_player_props (current lines) and get_player_games (raw game logs).

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?

"Use to see how a player did against his prop line over time" gives a clear triggering context, and "Set estimate_only to get the price without being charged" is an explicit usage instruction for the cost-averse path. It stops short of naming which sibling to use instead (e.g. get_player_props for current prices, get_player_games for non-prop logs), so no explicit alternative routing.

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 bar is lower; the description adds real value beyond them—result ordering ('strongest first'), the latest-by-default behavior, and a credit cost ('Costs 2 credits'). It omits return format details, but the output schema covers that.

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 tight sentences, each earning its place: purpose and ordering front-loaded, then the Elo interpretation, then the cost. No redundancy or filler.

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 explanation is unnecessary; the description still provides sort order, temporal default, the interpretive Elo gap heuristic, and cost—everything an agent needs to call and interpret results 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 coverage is 100%, so all three parameters are already documented in the schema. The description merely echoes the date default ('or as of date') without adding syntax, format, or behavior 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?

States a specific verb and resource ('our club Elo ratings') plus ordering ('strongest first') and a temporal scope ('as of the latest match (or as of date)'). This clearly distinguishes it from sibling tools like get_standings and get_team_stats, which return different metrics.

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?

'Use for our club Elo ratings' gives a clear usage context, reinforced by the date-scoping note. However, it does not explicitly name alternatives (e.g., get_standings for table position) or state when-not to use it, leaving routing 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, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds meaningful context beyond annotations: 2-credit cost and market-information handling restrictions. It does not discuss auth or error behavior, but it adds useful operational constraints.

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 front-loaded with the use case and scope, then gives the sibling alternative, cost, and usage constraints. Every sentence carries useful information with no filler or repetition.

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 and annotations already present, the description covers the remaining critical context: scope, returned market data, alternative tool routing, cost, and market-information constraints. Nothing essential for correct invocation 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 description coverage is 100%, so the schema already documents all three parameters. The description repeats the days default/range but adds no extra meaning for team or league beyond what the schema provides, making the baseline 3 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 a specific use case ('upcoming fixtures') with a precise time scope (next 1-30 days, default 7) and names the returned market data (median three-way line, moneylines, goal total, handicap, implied probabilities). It also explicitly distinguishes the tool from get_odds, which is for every book's line, so an agent can select it 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?

It gives explicit when-to-use guidance for upcoming fixtures and a clear alternative: 'For every book's line use get_odds.' It adds cost and usage constraints ('never work out a stake...'), so both selection and invocation boundaries are covered.

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 closed-world, so the description's added value is the response shape (totals, zones, per-shot coordinates) and, importantly, the 10-credit cost — a real behavioral constraint absent from every structured field. It does not state rate limits or behavior when no scope parameter is supplied.

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 scope then output, no filler. The opening "Use for a shot map:" lightly restates the title, and the dense parenthetical lists make it harder to scan than it needs to be, but 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?

With an output schema present the description didn't need to enumerate return fields, yet the extra detail is accurate and useful for choosing the tool. The one real gap is that all seven parameters are optional and the description never says what the default scope is when none are passed.

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; the description earns above that by explaining the interaction between `team` and `against` and by connecting `include_shots` to the presence of "every located shot" in the output. It still doesn't resolve the zero-required-parameter case (what happens if neither team, player nor game_id is given).

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 opens with an explicit verb+resource ("Use for a shot map") and then enumerates the three scoping modes: a club's shots, a player's shots, or one match's shots, with the `against` inversion called out. An agent knows exactly what data product it is requesting and what each scope yields.

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 when to reach for this tool and names the season default ("default: the latest"), plus the `against` variant. It does not point to a competing sibling (e.g. get_team_stats or get_events) or say when this tool is the wrong choice, so it falls short of full routing guidance.

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, closed-world behavior, so the safety profile is covered. The description adds genuinely new context: the 2-credit cost and the fact that Champions League returns one table per group or for the league phase, both of which affect invocation planning.

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 dense, front-loaded sentence plus a short qualifier and the cost note. The field enumeration is long but every item earns its place by telling the agent what it will actually receive.

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 rich annotations, a full output schema, and 100% parameter coverage, the description only needed to supply cost and the UCL edge case — both are present. Nothing an agent needs to call 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%, so the baseline is 3, but the description adds real meaning about the 'ucl' enum value: results are structured per group or as a single league-phase table rather than one flat table. It also frames 'season' as the table's season, reinforcing what the schema already documents.

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's league table) and enumerates the exact columns returned — rank, played, won, drawn, lost, goals, goal difference, points, notes, home/away records, form. This clearly separates it from stat-oriented siblings like get_team_stats or get_leaders, though no sibling is named 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 opening 'Use for a season's league table' is a direct usage cue and the UCL grouping note tells the agent what to expect per competition. However, there is no when-not guidance and no reference to an alternative tool for related needs (e.g., per-team stats or ratings).

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 description rightly focuses on things annotations cannot convey: the 5-credit cost and a concrete disclosure that possession coverage is missing for specific league-season combinations and that its average is computed only over matches that have it. That coverage caveat materially affects interpretation of returned 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 with purpose, then caveats, then cost — every sentence carries information. The metric enumeration is long but functional, since it defines the scope of the response.

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; with that off the plate, the description covers scope, a known data-quality limitation, and cost. Only the absence of alternative-tool routing keeps it short of 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?

Schema coverage is 100%, so team, league and season are fully documented in the schema, establishing the baseline of 3. The description only indirectly touches parameters by naming leagues (Eredivisie, Scottish Premiership, NWSL) in the coverage caveat, adding no format or semantics beyond the 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?

States a specific verb-and-resource: per-match season averages for clubs, split into for and against, with an explicit metric list. That makes it distinct from get_standings, get_ratings and get_leaders, though those siblings are never named as alternatives.

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?

'Use for clubs' per-match averages over a season' gives an implied usage context, but there is no when-not guidance and no pointer to the sibling tools an agent should pick for standings, ratings or team-level season totals.

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 genuine context the annotations don't carry: default sort order ('newest first') and a 2-credit cost. It says nothing about pagination mechanics or result volume beyond what the schema's offset field implies, so it stays at a solid 3 rather than fully informative.

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, zero filler. Purpose and filters come first, disambiguation second, cost last — a sensible front-loading for a listing 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?

With 10 parameters, no required fields, high schema coverage, a rich annotation set and an output schema, the description covers the essentials: scope, alternatives, ordering and cost. It could do slightly more on paging behavior given a limit/offset pair, but nothing critical 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 description coverage is 90% and the enum-filled stage/league/season/status fields are documented in-schema. The description echoes the filter dimensions (season, stage, date, date range, club) but adds no syntax, interaction rules, or defaults beyond those; baseline 3 is appropriate given the schema does the heavy lifting.

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 (list) and resource (fixtures and results), enumerates the filter dimensions, and specifies the default ordering ('newest first'). It is clearly distinguishable from get_schedule and get_game, which are named in the same sentence.

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?

Explicitly routes the agent: get_schedule for upcoming fixtures with lines, get_game for a single match in full. It also discloses the credit cost, which is a real decision input when an agent chooses among tools.

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/closed-world, so the description correctly spends its words elsewhere: it discloses the credit cost ('Costs 1 credit') and the default-season behavior, both of which the annotations do not 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?

Purpose and the sibling relationship are front-loaded in the first sentence, and the long league list is dense but each item disambiguates a slug. The enumeration is bulky, but little of it is filler.

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?

Output schema exists so return values need no explanation, and the description covers the two decision points (league, season default) plus cost. Only the 'soccer' vs 'Premier League' default naming is left slightly ambiguous.

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, and the description earns above that by mapping human-readable league names to enum slugs ('La Liga' -> laliga, 'Brazil's Serie A' -> brazil), which helps an agent pick the right enum value. Minor gap: it does not mention the 'soccer' enum value and instead calls the default 'the Premier League', slighting diverging from the schema's stated default.

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 ('find club ids and abbreviations for a season') and explicitly positions itself relative to all siblings ('Every other tool takes a club as an id, abbreviation or name'), so an agent knows exactly what it retrieves and why.

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?

Gives clear usage context: call this to obtain club identifiers before invoking any other tool, and pass 'league' to scope it. It lacks an explicit 'don't use this for X' exclusion, but the prerequisite role is unambiguous.

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 description's job is lighter; it still adds the credit cost ('Costs 1 credit') and the accent-insensitive matching behavior, both of which are real traits not captured in structured fields.

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, front-loaded with the purpose, then scope, then return shape, then cost. No filler.

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 the return-value sentence is redundant but harmless. Purpose, cost and the accent nuance are covered; only the undocumented 'limit' parameter and the absence of routing to get_player leave small 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 75% with documented name/team/league, so the baseline is already high; the description nonetheless adds meaning by clarifying accents are optional and that the club filter is optional rather than required.

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 ('find a player's id by name') plus the scoping options and the returned fields. It implicitly separates itself from get_player (id lookup vs. name lookup), though it never names that sibling 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 phrase 'Use to find a player's id by name... optionally within a club' implies the lookup scenario, but there is no explicit when-not guidance and no named alternative (e.g. get_player) for the case where the id is already known.

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