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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context by noting the data source is ball-by-ball archives and clarifies the available metrics. It does not describe result ordering, default kind/limit, or pagination, but those defaults are in the 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?

Two concise sentences with no fluff. The purpose is front-loaded, and the supported leagues and data source are listed efficiently. Every word adds value.

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

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

For a simple read-only leaderboard tool with fully documented params and a safety profile from annotations, the description is largely complete. It could optionally state what fields the leaderboard returns, but 'most runs or most wickets' already conveys the core output. The lack of an output schema is mitigated by the clarity of 'leaderboard.'

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 reinforces that 'kind' maps to runs vs wickets and that 'year' is optional, but it does not add meaning beyond the schema's own parameter descriptions.

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 provides leaderboards for a league and optional season, with most runs or most wickets as the key metrics. It names specific supported leagues, which adds concreteness. However, it lacks an explicit verb and does not distinguish itself from sibling cricket stats tools like phase_stats 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 implies when to use the tool: whenever you need league leaderboards for runs or wickets. It gives no explicit alternatives or when-not-to-use guidance, nor does it mention conditions that would favor a sibling tool. Usage context is present but left to inference.

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

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

Annotations already indicate readOnlyHint and openWorldHint, so the description's role is lighter. It adds useful context by naming the public feed source (ESPNcricinfo) and the caveat 'where available', which signals that scores may be missing. There is no contradiction with annotations, but no further behavioral detail such as refresh behavior is provided.

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 a single concise sentence that packs in the resource, scope, score availability, and data source. Every word earns its place, and useful information is front-loaded without superfluous detail.

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 no-parameter tool with no output schema, the description conveys the core return content: live/upcoming matches and scores where available. It does not specify output structure or data freshness, but those are less critical given the tool's simplicity and the read-only annotations.

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

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

The tool has zero parameters, so the schema coverage is trivially 100%. The baseline for a no-parameter tool is 4; the description appropriately does not need to explain parameter meaning and does not introduce confusion.

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 identifies the specific resource (currently live and upcoming cricket matches) and adds scope via the ESPNcricinfo source. It distinguishes itself from siblings like cricket_match_archive (past matches) and other stats-focused tools, though it uses a noun phrase rather than an explicit verb like 'list' or 'get'.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The phrase 'currently live and upcoming' implies it is for current matches, but it does not say to use cricket_match_archive for historical data or mention any other exclusions or alternative conditions.

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 meaningful behavioral context: the data is live, sourced from a regulated exchange, expressed in cents as implied probabilities, and carries legal/advice 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, an interpretation rule, and necessary caveats without waste. The most important information is front-loaded, and 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 read-only odds tool with no output schema, the description explains the data source, the meaning of the numeric output, and the comparison purpose. It doesn't specify error cases or the exact response shape, but those are minor given the simple two-parameter request and read-only annotation.

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?

Input schema has 100% coverage with clear examples for both required parameters, so the baseline applies. The description doesn't add parameter-level detail beyond the schema, though it does clarify how the returned values should be interpreted.

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 action — retrieving live prediction-market prices from Kalshi — and clearly identifies the resource as cricket match odds. It also distinguishes itself from the server's own win probability, separating it from sibling tools like cricket_win_probability without ambiguity.

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 conveys the use case: comparing live market prices against this server's own win probability, which implies when to select this tool over a probability-only tool. However, it doesn't explicitly name sibling tools or state when not to use it, so it stops short of full exclusionary 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 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?

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that data is 'archived' and describes result content, but it does not clarify response ordering, pagination, or how open-world data is scoped. This is adequate but not rich behavioral 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?

The description is a single compact sentence with the core subject 'team's most recent archived results' front-loaded and no filler. It earns its place by conveying both purpose and output content efficiently.

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 low-complexity read-only tool with two parameters, the description is largely complete: it names the resource, the recency scope, and the return fields (opponent, outcome, match event). There is no output schema, so a bit more detail about response structure or sort order would be helpful, but the gap is minor given the simple shape of the 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 description coverage is 100%, with 'team' and 'limit' already explained. The description does not add parameter-level nuance; it describes the result fields rather than the parameters, so the baseline 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 clearly states that the tool returns 'a team's most recent archived results' and lists the output content: opponent, outcome, and match event. The word 'archived' differentiates it from live-match tools, and the team-centric focus separates it from player, venue, and leaderboard 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 phrase 'for reading current form' gives a clear use context, so an agent can infer when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, such as when a head-to-head comparison or live match data is needed.

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 indicate readOnly and non-destructive behavior. The description adds useful model context: logistic model fitted on 8,000+ archived matches, per format and innings, with pre-match Elo, and clarifies the output includes batting-side probability and favored side. This goes beyond what annotations provide.

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 front-loaded with the core purpose, followed by model provenance and concrete use cases. All three sentences contribute value, though the phrasing 'who is favored' and the quoted use cases could be slightly more formal.

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 no output schema, the description adequately states what the caller receives: the batting side's probability and who is favored. With 9 parameters all documented in the schema and annotations covering safety, the description is sufficient for an agent to understand scope and output. Some edge-case behavior around innings and target is left implicit, but the schema fills that gap.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description does not add further parameter-level detail but does clarify that the returned probability applies to the batting side, which is mildly helpful context.

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 computes win probability for a live or hypothetical limited-overs match state and returns the batting side's probability and favored side. It is specific enough to distinguish from siblings like cricket_live_matches or cricket_match_archive, though it does not explicitly name a sibling alternative.

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' or 'what are the odds at X/Y'. This provides clear context for when the tool is appropriate, though it does not mention when not to use it or explicitly compare it to alternatives like cricket_market_odds.

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