mcp-cricket

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

Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds conceptual background about the metrics' importance but discloses no additional behavioral traits such as default perspective, data coverage, or output structure. It does not contradict annotations, but it fails to add meaningful behavioral context beyond them.

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 concise and front-loaded with the core metrics, followed by a sentence explaining relevance. The second sentence adds value by clarifying rarity of data, though it could be trimmed; still, it is 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?

With no output schema, the description should clarify what is returned, but it only states which metrics are computed without describing the response shape. Given the simple parameter set and read-only annotations, coverage is adequate but not complete; an agent might still wonder about format or default behavior.

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 parameters. The description echoes the bowler/batter distinction already present in the perspective field, but it does not enrich parameter meaning (e.g., how total_overs affects results). Baseline 3 is appropriate given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the resource (bowler or batter) and the specific metrics computed (dot-ball percentage, boundary percentage, economy). It distinguishes itself from siblings like cricket_dismissals and cricket_head_to_head by focusing on rates that scorecards don't show, leaving no ambiguity about what the tool does.

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 by explaining that these numbers are decisive in limited-overs games and not available on scorecards, suggesting when an agent might need them. However, it does not explicitly contrast with sibling tools or state when not to use this tool, leaving alternatives unaddressed.

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 and destructive false, so no contradiction. The description adds non-obvious behavioral context: run outs are excluded from bowling because they are not credited to the bowler, and results are aggregated counts/shares across the ball-by-ball archive. This is useful beyond the annotated metadata.

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 fluff. The primary purpose is front-loaded, and the caveat about run-outs is placed meaningfully. Every sentence contributes to selection and invocation correctness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read-only tool with no output schema, the description gives a complete picture: what data is returned, what the two perspectives are, and a key exception. An agent has enough to decide whether this tool fits and to call it without surprises.

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 baseline is 3. The description adds semantic depth by explaining what each perspective means ('how they get out' vs 'how they take wickets') and clarifies an important detail about run outs in the bowling perspective. This enriches the interpretation of the 'perspective' 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 states the tool's resource and purpose: how a batter gets out or how a bowler takes wickets, with specific dismissal types and output of counts and shares. It distinguishes the batting and bowling perspectives, making it easy to differentiate from sibling cricket tools.

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 contextual guidance by explaining the two possible perspectives (batting vs bowling) and the meaning of each. It clearly notes that run outs are excluded from the bowling view, which is essential for correct interpretation. It does not explicitly mention alternative tools, but the context is strong enough for its niche.

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 and destructiveHint=false. The description goes beyond that by revealing the response style ('plain English'), the comparative output ('closest baseball equivalent'), and the scope ('~60 more' terms). It doesn't cover unknown-term behavior, but the annotations carry the safety profile and the added context is useful.

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 states the action, output format, and scope with no filler. Every part of the sentence earns its place, and the examples improve comprehension without bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, read-only, single-parameter lookup tool, the description is complete: it explains what the tool does, what kind of output to expect, and gives a sense of the covered terms. Annotations cover side effects, sibling context disambiguates from stats tools, and no output schema is necessary for such an explanatory response.

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% for the single parameter, so the schema already fully documents 'term'. The description reinforces it with examples and scope, but does not add meaningful new semantics beyond what the schema provides. 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 uses a specific verb ('Explain') and a clear resource ('a cricket term'), and adds a distinctive output feature ('closest baseball equivalent'). It also lists concrete examples, making the tool's purpose immediately distinguishable from the statistical sibling tools.

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 makes the use case clear: this is a terminology-explanation tool, not a stats or data tool. It does not explicitly name alternatives or exclusions, but the sibling list is all data/analytics tools, so the contrast is strong and the intended usage is evident.

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 read-only and non-destructive behavior. The description adds useful context beyond annotations by identifying the data source ('ball-by-ball archives') and the nature of the data (career-level record), which helps set expectations about scope and granularity.

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: the first states the purpose and output fields, the second gives a useful analogy for familiarity. No filler or repetition; every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only lookup with fully documented parameters, the description is sufficient. It names the output metrics and data source, and the schema covers the format defaults. A caveat about missing/insufficient ball-by-ball data could add completeness, but is not essential 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 description coverage is 100%, with batter, bowler, and format all documented. The description reinforces the head-to-head nature but does not add parameter-specific detail beyond the schema, so the baseline of 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 a specific resource ('Career batter-vs-bowler record') and enumerates the exact metrics returned (balls faced, runs scored, dismissals, strike rate), making it immediately clear what the tool does and how it differs from general player career or phase stats tools.

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 this tool is for batter-vs-bowler head-to-head queries, but it does not state when to prefer it over siblings like cricket_player_career, cricket_phase_stats, or cricket_match_archive. No explicit usage context or exclusions are provided.

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 only declare readOnly/openWorld/non-destructive; the description adds data-provenance caveats that annotations cannot carry, e.g. Cricsheet publishes no Afghanistan men's matches, so t20i/odi/test men's lists omit those players, and which leagues mix men's and women's games. That is genuinely useful for interpreting results. It does not describe ordering, pagination, or what happens on an unknown league code.

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 purpose sentence is correctly front-loaded, but the remaining text is an unstructured wall of semicolon-clause taxonomy that is hard to scan and repeats the schema's gender/members wording. Most sentences do carry information, so it is dense rather than padded, but it is not well organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter tool with no output schema, the description thoroughly covers the hardest dimension (league scoping, gender, members) but omits other things an agent needs: the sort direction (are leaders returned highest-first?), the meaning of 'kind' beyond the schema's one-liner, and the year format nuance. Return-shape omission is excused by the absent output schema, but ordering is not.

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 goes beyond the schema by defining the league taxonomy itself (t20 = T20Is plus code-less domestic T20; t20i = T20Is alone), which the schema only labels as 'league code, e.g. mlc, ipl'. It partially duplicates the gender and members semantics already in the schema, but the league expansion adds real meaning.

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 and resource: 'Leaderboards for a league and optional season: most runs or most wickets, from ball-by-ball archives.' That clearly separates it from siblings like cricket_player_career or cricket_phase_stats. It stops short of 5 because it never names a sibling it is not, so the agent must still infer the boundary against cricket_situational or cricket_minor_league.

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 bulk of the text is context for invoking the 'league' parameter correctly (t20 vs t20i, gender default behaviour, members 'full'), which is real usage guidance for a tricky dimension. But there is no explicit when-to-use-this-vs-alternative routing and no exclusions against the many sibling leaderboard-adjacent 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context: the data comes from ESPNcricinfo public feeds and Kalshi's live data, and scores are conditional ('where available'). This goes beyond the annotations and helps set expectations about data source and completeness.

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 core purpose and appends the data-source details parenthetically. Every word earns its place, with 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?

For a parameterless read-only tool with no output schema, the description is complete: it states the subject (live/upcoming cricket matches), the conditional data field (scores), and the sources. An agent can call it without needing additional context about inputs or expected returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so there is nothing to document. The baseline of 4 applies because the description need not explain parameters that do not exist, and it successfully communicates the tool's non-configurable, retrieval-style behavior.

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 (cricket matches) and its scope (currently live and upcoming, with scores where available), which distinguishes it from siblings like cricket_match_archive. However, it lacks an explicit action verb such as 'list' or 'get', relying on the noun phrase 'Currently live and upcoming cricket matches' to imply retrieval.

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 when to use this tool—when the user wants live or upcoming cricket matches and scores—but it does not explicitly contrast it with alternatives such as cricket_match_archive or cricket_minor_league. The mention of Minor League Cricket from Kalshi's live data hints at overlap with cricket_minor_league, yet no exclusion or selection guidance is provided.

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, but the description still adds substantial behavioral context: prices are cents equal to implied probability, the Kalshi exchange is CFTC-regulated, Minor League Cricket prices follow cricket_minor_league's rule only when Kalshi's book is real, and the tool is informational only with legal caveats. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences deliver the core purpose first, then price interpretation, then edge-case and legal details. It is slightly dense and the Minor League Cricket sentence is convoluted, but every sentence contributes useful information rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by explicitly explaining the output format ('42 means the market prices a 42% chance'). The two parameters are fully documented in the schema, annotations cover read-only safety, and the description covers behavior and caveats. Nothing essential 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%—both team_a and team_b have descriptions and examples. The tool description adds no additional parameter-specific meaning (e.g., format constraints or team-name normalization), but per the baseline for high schema coverage, a score of 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 opens with a specific verb and resource: 'Live prediction-market prices for a cricket match from Kalshi... shown beside this server's own win probability.' This clearly states what the tool does and differentiates it from siblings like cricket_win_probability (model probability) and cricket_minor_league (overlapping market rule).

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 text implies usage context—comparing Kalshi market prices to the server's own win probability, and noting a Minor League Cricket crossover with cricket_minor_league. However, it never explicitly states when to prefer this tool over alternatives or provides exclusions, leaving the guidance 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=true and destructiveHint=false, so safety is covered. The description adds useful behavioral detail about the lookup scope and the returned data, including that it searches by team names, league, and year, which goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, with the core action and return value front-loaded. No filler or repetition, and every phrase contributes to selection and 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 no output schema, the description still explains the return value (scorecard components) and the acceptable search inputs. It is adequate for a simple one-parameter lookup, though a note on the absence of Test matches or the meaning of 'limited-overs' could marginally improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% coverage for the single free-text query parameter, so the baseline is already solid. The description adds meaning by specifying the search dimensions: team names, league, and/or year, which clarifies how the free-text query should be composed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Look up') with a clear resource ('archived limited-overs match') and states the concrete return payload ('scorecard: innings totals, top scorers, leading wicket-takers'). It clearly distinguishes this from live-match and aggregate-stat siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool: searching archived limited-overs match scorecards by team, league, or year. It does not explicitly name alternative tools or state when not to use it, but the 'archived' qualifier and focus on match scorecards provide a practical usage boundary.

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/openWorld/non-destructive annotations: it names the upstream feed (Kalshi public live data), the precise time window, the win-chance semantics (midpoint only when the book is a real price, model only during the chase), known limitations (no ball-by-ball, no batters or bowlers), and fallback behavior ('If nothing is on, it says when the next game is').

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?

Dense and front-loaded, leading with what the tool returns and its data source before caveats. It is a single long paragraph whose clauses all carry information, though it could be split for 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?

With no output schema, the description carries the burden of describing returns and does so: each game's state, start time (ET), score, chase requirement or result, and win chances. Failure mode (nothing on) and coverage limits are also stated, so an agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single 'team' parameter, so the schema already carries the full matching semantics (full or partial name, omit for all games). The description adds no syntax or format detail beyond that, 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?

States a specific verb+resource: 'Scores and win chances for Minor League Cricket... from Kalshi's public live data,' with the exact data source named. It also explicitly distinguishes itself from the sibling cricket_minor_league_info, which owns history, teams, grounds and players.

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?

Clear inclusion conditions are given (live, starting within 3 hours, or finished in the last 2 hours) plus the routing rule to cricket_minor_league_info. It does not explicitly contrast with other live/odds siblings like cricket_live_matches or cricket_market_odds, so exclusions are partial.

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 safety (readOnly, non-destructive, openWorld), and the description adds substantial context beyond them: exact provenance of each dataset, licensing (CC BY-SA 4.0), freshness ('how current it is'), explicit statement of what data lacks, and whole-name matching that returns a question rather than another player's figures. This is unusually rich failure-mode disclosure.

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 sourcing are front-loaded, then a compact semicolon-delimited tour of argument combinations. Every sentence carries information, but the single dense paragraph is longer than ideal and could be split for 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?

For an 8-parameter, all-optional tool with no output schema, the description covers the combination logic, defaults, provenance, currency, and answer format ('exact figures, its source and how current it is'). Nothing an agent needs to call it 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; however the description adds cross-parameter combination semantics (team+opponent+date for a fixture, player+team for disambiguation, season narrowing other arguments, default 2026) that the flat schema cannot express. It stops short of adding per-parameter syntax beyond what the schema already gives.

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 ('Player records and league history for Minor League Cricket') and immediately scopes the data (CricClubs scorecards 2026, results/grounds 2023-2026, Wikipedia squads 2021-2024). It also names the sibling it is not, cricket_minor_league, for live scores, so the agent can separate the two 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?

Enumerates concrete usage patterns for every argument combination (player, team+opponent, ground, leaders+season, season alone, topic, no arguments) and states the fallback behavior when no arguments are given. It explicitly routes live-score queries to cricket_minor_league.

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 and destructiveHint=false, so safety is covered. The description adds valuable context about how stands are reconstructed by segmenting innings at wickets, and explains a limitation of the archive (only striker recorded). This goes beyond the annotations and helps the agent understand data provenance and potential edge cases.

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 concise and well-structured: the first sentence states the output content, the second sentence explains the reconstruction method. No redundant words, and the most important information is front-loaded. It earns a top score for efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only tool with no output schema, the description explains what is returned (runs, stands, best) and how the data is derived. It does not specify output formatting or sorting, but that is a minor gap given the simplicity and the annotations covering safety. The description is sufficient for an agent to invoke 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%: both parameters (player, limit) are described in the schema. The description does not add new parameter-level details beyond the schema, but it does clarify the meaning of 'partnerships' and 'stands'. This meets the baseline for a tool with full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: it returns a batter's most productive partnerships, including runs added, how many stands, and their best. It uses a specific resource (partnerships) and provides detail, though it does not explicitly distinguish it from sibling tools, so it falls short of a 5.

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 guidance on when to use this tool compared to other cricket tools. The description implies that it is for exploring partnership statistics, but it does not mention alternatives or conditions that would make this tool preferable. No exclusions or contextual advice is provided.

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 and destructiveHint=false, so the safety profile is covered. The description adds a useful data-source detail ('computed from ball-by-ball archives') but does not disclose player-name matching behavior, data availability, or behavior for unsupported formats. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is concise and front-loads the core purpose. The second sentence is rhetorical flavor about separating 'a strike-rate merchant from a genuine finisher' and does not help an agent select or invoke the tool, so not every sentence earns its place.

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?

The tool is simple with two parameters and strong schema coverage, and the core query intent is clear. However, there is no output schema and the description does not indicate what metrics or fields the result will contain, leaving some uncertainty about the returned shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents both parameters with 100% description coverage, so the baseline is 3. The tool description adds no parameter-specific detail beyond the schema, though it does clarify the batting/bowling split that the player name parameter relates to.

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 a player-performance stats tool broken down by innings phase (powerplay, middle overs, death) for both batting and bowling. It lacks a direct imperative verb like 'retrieve' or 'calculate', and it doesn't explicitly distinguish itself from sibling player-oriented tools, but the phase-split scope is specific and recognizable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool over cricket_player_career, cricket_team_form, or cricket_venue_stats. It only mentions that the data is computed from ball-by-ball archives, which implies historical analysis but does not help an agent choose between alternatives.

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 and destructiveHint=false, so the safety profile is covered and nothing is contradicted. The description adds valuable context beyond annotations: data provenance (Cricsheet ball-by-ball archives), gender coverage (men's and women's), and per-format aggregation behavior — all non-obvious traits the agent would not know otherwise.

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: purpose leads, followed by source, stat list, and the per-format qualifier. There is no filler, no repetition of schema content, and every clause adds information an agent needs to select and invoke the 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?

For a one-parameter read-only tool with no output schema, the description covers scope, data source, returned fields, and per-format grouping — enough to form an accurate mental model of the result. Minor gaps are the lack of explicit return-structure detail and name-matching behavior for unknown or ambiguous players, but these are unlikely to block 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 description coverage is 100% — the single `name` parameter already has a description with a concrete example ('Rachin Ravindra'). The tool description adds no parameter-specific meaning beyond what the schema provides, 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 precise scope — 'Career aggregate statistics for a player' — with a specific resource (player), a concrete stat list (innings, runs, strike rate, average, high score, wickets, economy), and per-format grouping. The single-player career framing differentiates it from siblings like cricket_head_to_head (two players), cricket_leaders (rankings), and cricket_phase_stats without needing to inspect their 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?

When to use the tool is implied by the purpose statement — when an agent needs career aggregates for a single player — but no explicit when/when-not guidance or alternative tools are named. An agent must infer that head-to-head comparisons belong to cricket_head_to_head or that phase-level breakdowns belong to cricket_phase_stats.

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 convey read-only and non-destructive safety. The description adds beyond that by disclosing the exact output fields (runs, balls, average, strike rate for each scenario) and the policy of excluding multi-day rather than guessing, giving the agent confidence about what it will and will not return.

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 core purpose, and each sentence is information-dense. The second sentence provides necessary context about the exclusion without fluff. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with only two parameters (one required) and no output schema, the description fully covers what is returned (runs, balls, average, strike rate per scenario) and the scope (limited-overs, batting-first vs chasing). Annotations cover safety, so the description is complete for an agent to invoke 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 coverage is 100% for both parameters (player and total_overs), with clear descriptions already explaining player name format and format restriction. The description does not add further parameter-level detail beyond what is in the schema, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: reporting a batter's batting record when batting first versus chasing in limited-overs cricket, with specific metrics (runs, balls, average, strike rate). The phrasing 'batting first versus chasing' and explicit exclusion of multi-day cricket differentiates it from sibling tools like cricket_player_career or cricket_phase_stats, even without naming 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?

The description specifies the context (limited-overs cricket) and explicitly states when NOT to use it (multi-day cricket), citing the incomparability of innings. It does not explicitly name alternative tools, but the exclusion of multi-day and the focus on situational splits clearly delineates its scope among the cricket siblings.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds a genuine non-obvious caveat — that the archive stores a country's men's and women's sides under one name, which explains the gender parameter's purpose. It says nothing about limits beyond the default or rate behavior, but the added naming caveat is real 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 core purpose and return fields before the parameter guidance. No filler, though the second sentence reads slightly awkwardly and the ordering could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by naming the return fields (opponent, outcome, match event). All four parameters are documented in the schema, and annotations cover the safety profile, leaving little an agent needs that 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 justifies the gender parameter by explaining the shared-naming model ('the archive gives a country's men's and women's sides one name'). That tells the agent why gender exists and what omitting it yields, adding meaning beyond the schema's terse 'Omit for both'.

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 verb-and-resource combination ('a team's most recent archived results... for reading current form') and enumerates the returned fields (opponent, outcome, match event). It is clearly distinct from data-heavy siblings like cricket_match_archive or cricket_head_to_head, though it does not explicitly name those 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?

Usage is implied by 'for reading current form' and by the instruction to pass gender/format for one side, but there is no explicit when-to-use versus when-to-use-a-sibling guidance (e.g., versus cricket_head_to_head or cricket_match_archive). The reader must infer the routing from the stated purpose.

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, non-destructive behavior. The description adds useful behavioral context by enumerating the key stats returned and framing them as historical venue tendencies. It does not explain output formatting or edge cases, but the core read-only behavior is reinforced rather than contradicted.

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 two sentences with no filler. It front-loads the core concept ('How a ground plays'), lists the meaningful stats, and ends with a practical use case. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only stats tool with only one required parameter and full schema coverage, the description is complete. It tells the agent what the tool computes, why it matters, and how to apply the results. No output schema exists, but the described metrics give a sufficient mental model of 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 description coverage is 100%, so the schema already documents both parameters well, including the venue example and the total_overs defaults. The description adds no new parameter-level detail, but the baseline of 3 is appropriate because the schema carries the necessary semantic load.

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 ('a ground') and the specific purpose: summarizing how a venue plays. It lists concrete outputs (matches recorded, average first-innings score, highest total, chasing-side win rate), which makes the tool's function unambiguous and distinct from the sibling tools like head-to-head or team form.

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 states when to use this tool: 'for toss decisions and pre-match reads.' This gives the agent a clear context for invocation. It does not explicitly name alternative tools or when-not-to-use conditions, but the use case is well implied by the venue-specific scope.

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 mark the tool as read-only and open-world; the description adds useful context by specifying the model basis ('8,000+ archived matches', per format and innings, pre-match Elo) and the output shape (per-side probability and favored side). It does not cover limitations or edge cases, but it complements rather than contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: it opens with the core computation, then gives invocation patterns, return values, and example use cases in just four sentences. There is minimal redundancy, and the most important context is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool without an output schema, the description adequately covers what the tool returns and when to use it. However, it is incomplete about how to encode a not-yet-started fixtures under the required fields, and it does not explain probability semantics, leaving some ambiguity for the agent to infer.

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 descriptions cover all nine parameters in detail (100% coverage), so the baseline is a 3. The description adds an invocation pattern ('pass a state' vs two team names), but it does not clarify how a pre-match call can satisfy the five required numeric state fields, which keeps it at the baseline rather than above it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool computes: win probability for a limited-overs match, live or hypothetical, based on a logistic model. It also names the return value ('each side's probability and who is favored') and gives concrete example queries, making it easy to distinguish from siblings like cricket_market_odds.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit use cases ('who is winning', 'what are the odds at X/Y', 'who is favoured tomorrow') and separates in-play state usage from pre-match team-name usage. It does not name alternatives or exclusions, and the 'just two team names' hint is not fully reconciled with the required numeric schema fields, so it falls short of a 5.

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