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

Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds behavioral detail by specifying it checks both reachability and plan, providing valuable context 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: the first states the core action, the second provides usage context. No unnecessary words.

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 diagnostic tool with no parameters and an output schema available, the description fully covers purpose and usage context, making it complete for selecting and invoking 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?

The tool has no parameters, and schema coverage is 100%. Per guidelines, baseline is 4; the description does not add parameter semantics but none are needed.

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 checks API reachability and plan. This distinguishes it from sibling data-retrieval tools like get_fixtures or get_live_matches, which focus on specific data rather than API status.

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 explicitly states the tool is 'useful for diagnosing why other tools are refusing data', providing clear context for when to use it and implying alternatives (sibling tools) for normal data retrieval.

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

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

Beyond the annotations (readOnly, openWorld, idempotent), the description discloses an important data caveat: serve stats are only recorded from 1991 and matches_with_stats indicates coverage. It also explains the ambiguity resolution behavior. This is valuable added context, though not exhaustive in terms of pagination or rate limits.

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, with a clear front-loaded purpose followed by necessary caveats and requirements. Every clause contributes useful information with no wasted words.

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?

Given a single parameter, rich annotations, and an output schema, the description fully covers key usage rules, data limitations, and disambiguation behavior. It does not need to explain return values because the output schema is present. No significant gaps remain.

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

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

The schema already fully documents the 'name' parameter with type, minLength, and a description. The tool description reinforces the resolution requirement and explains that an ambiguous fragment returns a candidate list, providing context beyond the schema. This justifies a score above the baseline of 3.

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 returns a single player's entire career over the results archive (1968–2022), including W-L record, titles, and serve statistics. This scope distinguishes it from sibling tools like get_archive_match or get_player, making the purpose highly specific.

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

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

It provides clear context on when to use the tool (for full career archive aggregates) and includes explicit requirements: the name must resolve to exactly one person, and a plan is required. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops 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.

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

Goes beyond annotations by disclosing that serve stats are null for most pre-1991 rows and that data is never synthesized. Also states the access plan requirement. Annotations already indicate read-only/idempotent, so the description adds honest data-quality context.

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 clause adds value (time range, stats caveat, plan). No fluff, despite the informal 'honestly' which conveys transparency rather than 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 single-parameter retrieval tool, the description covers the key caveat (null stats before 1991) and access requirement. Output schema exists and handles return format, so no further detail is needed.

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 description does not add meaning beyond the input schema, which already fully describes archive_match_id including its source. With 100% schema coverage, baseline 3 is appropriate; no additional parameter nuance is provided.

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?

Clearly states the tool retrieves a single archived result (1968–2022) with serve statistics, distinguishing it from siblings like get_match (likely live) and search_archive_matches (search). The verb 'get' and specific resource 'archive result' are explicit.

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?

Implies use for archive results and specifies plan requirements, but does not explicitly contrast with siblings or state when not to use. The archive context and plan condition provide practical guidance, though exclusions are absent.

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 the tool as read-only and idempotent. The description adds valuable context: the per-set split is 'exactly as charted' (no processing), and the ULTRA plan requirement is disclosed. This supplements the annotations without contradicting 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 two sentences with the core function first, followed by two important clarifications. Every sentence earns its place, with no redundancy or fluff.

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

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

For a single-parameter retrieval tool with an output schema, the description covers scope, ID semantics, and access requirements. The output schema handles return-value details, so no further elaboration is needed.

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

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

The schema already documents charting_match_id well, and the description reinforces its meaning by clarifying that charting IDs are a separate ID space from match_id. This adds practical guidance beyond the field description.

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: it returns every Match Charting Project stat family for one charted match, including both players and per-set splits. It distinguishes from sibling tools by explicitly noting charting IDs are their own ID space with no live-table counterpart.

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 context is clear: use this when you need charting data for a single match, especially when the match has no live-table equivalent. It does not explicitly name alternative tools, but the ID-space distinction and 'ULTRA plan' requirement effectively guide selection.

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

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

Beyond annotations, the description discloses that coverage is curated (11,646 matches, concentrated on majors) and that ambiguous names return candidate choices. It also notes the ULTRA plan requirement. These are non-obvious behavioral traits that help set expectations.

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 information-dense but well-organized, front-loaded with the core purpose. The metric list is exhaustive yet each item adds value, and the coverage and plan notes are clearly highlighted. No fluff 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?

Given the tool's complexity and that an output schema exists, the description covers the data source, coverage scope, ambiguity handling, and plan requirement. It gives enough context for an agent to know when to expect partial data and what inputs are needed. No significant gaps remain.

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 descriptions already cover both parameters well (100% coverage). The description adds the behavior that an ambiguous name returns candidates, clarifying how the name parameter resolution works beyond the schema's 'must resolve to one charted person'.

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 it provides a 'career shot-level profile from the Match Charting Project' listing specific metrics (serve placement, return depth, net play, etc.), which distinguishes it from siblings like get_charting_match (match-level) and get_player (general profile). The scope is explicit: summed over charted matches.

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 (for aggregated career charting stats) and notes prerequisites like 'Requires the ULTRA plan' and the ambiguous-name behavior. However, it does not explicitly mention alternatives or exclusions, such as 'for a single match use get_charting_match'.

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 disclose read-only, idempotent, open-world behavior. The description adds that results are ordered earliest first and are exclusively scheduled/forward-looking, adding behavioral context beyond the annotations without contradicting 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 a single short sentence, but 'the forward schedule' is largely redundant with 'Upcoming scheduled tennis fixtures'. Still, it remains compact and 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?

With an output schema present, annotations covering safety, and schema covering parameters, the description's addition of ordering and scope makes it complete for a simple list 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?

Both parameters have full schema descriptions (tour enum and limit range), so the description adds no parameter-level semantics. The schema covers the meaning, giving the baseline of 3.

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 the resource (upcoming scheduled tennis fixtures) and ordering (earliest first), clearly indicating it provides the forward fixture schedule. It lacks an explicit verb but is unambiguous and distinct from result/live tools, though it doesn't name sibling 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?

The phrase 'the forward schedule' implies this tool is for upcoming fixtures, contrasting with results or live matches. However, it does not explicitly state when to use it vs get_upcoming_matches or get_recent_results, so usage guidance is implied rather than explicit.

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

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

Beyond the readOnly/idempotent annotations, the description discloses critical behavioral details: ambiguous fragments return a candidate list, totals exclude matches without a known winner, walkovers/retirements are included, and each meeting carries an outcome. Also states plan requirements.

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

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

Four sentences, each conveying essential information with no redundancy. The main purpose is front-loaded, followed by input behavior, counting rules, and access requirements. 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 has only two parameters, an output schema, and strong annotations. The description covers purpose, scope, edge cases, counting semantics, and access requirements, making it complete for the tool's complexity.

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

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

The schema already fully documents both parameters with examples. The description adds value by explaining that names are keys and that ambiguous fragments trigger a candidate list, enriching the semantic understanding beyond the schema.

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

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

The description clearly states the tool's function: retrieving the all-time head-to-head record between two players across both the archive (1968–2022) and completed matches (2023 onward). This specific verb+resource+scope distinguishes it from sibling tools like get_archive_career or get_match.

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?

Provides clear context on when to use (for head-to-head records) and how input works (fragments, ambiguity handling). It doesn't explicitly name exclusions or alternatives, but no sibling tool serves the same purpose, so the guidance is strong.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful scope coverage (ATP, WTA, Challenger, ITF, juniors) but does not add deeper behavioral details like data freshness, pagination, or rate limits. This matches the baseline for annotations covering safety.

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, front-loaded with the core action, and every phrase earns its place. No filler or redundancy.

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

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

Given the tool's simple read-only nature, complete schema documentation for all four optional parameters, and a provided output schema, the description adequately covers what the tool does and when to use it. No gaps that would hinder an agent's 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%, so the baseline is 3. The description mentions tour coverage, but the schema already provides enum values and detailed descriptions for each parameter. The description adds no new semantic meaning beyond what the schema already conveys.

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 ('List') and resource ('tennis matches currently in progress, with live scores'), clearly distinguishing it from siblings like get_upcoming_matches or get_fixtures. The phrase 'what tennis is on right now' reinforces the unique scope of live/in-progress matches.

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 explicitly tells the user when to use this tool ('Use this for "what tennis is on right now"'), providing clear context. It does not, however, name alternatives or specify exclusions compared to sibling tools, 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.

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

Annotations already declare read-only and idempotent behavior. The description adds valuable context about plan-dependent content (market prices on PRO, model analysis on ULTRA) and lists the specific fields included, which helps set expectations about the response. No contradiction with annotations.

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

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

The description is two sentences. The first sentence front-loads the core purpose and key fields; the second sentence adds plan-specific context. No superfluous words.

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 description, combined with the schema and annotations, fully covers what the tool returns and the variations by plan. The presence of an output schema means return formatting doesn't need to be described. Minor gap: it doesn't explicitly state behavior on free tiers, but the output schema likely signals optional fields.

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 for match_id is 100%, and the schema already explains the parameter's provenance (as returned by other tools). The tool description adds no additional parameter meaning beyond 'by id', 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 clearly identifies the tool as retrieving full details for a specific match by ID, and enumerates the key fields (players, score, surface, round, status), which distinguishes it from sibling tools focused on specific aspects (e.g., get_match_score, get_match_odds). The verb 'get' is implicit in the name, but the phrasing 'Full detail for one match by id' is a specific and unambiguous purpose.

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 for retrieving comprehensive match information rather than a specific sub-detail, but it does not explicitly contrast with alternatives like get_match_score or get_match_analysis. The plan-dependent note ('on PRO and ULTRA') provides context for content availability, but not when to choose this tool over others.

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 known. The description adds the ULTRA plan requirement and specifies the output contents, which is valuable context beyond 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 one sentence that front-loads the core purpose and provides key contents and the plan requirement. Every phrase adds value without redundancy.

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

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

With a comprehensive output schema and safe read-only annotations, the description covers the core aspects. It includes the plan requirement and return contents, making it adequate for a single-parameter analysis tool.

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

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

The input schema fully documents match_id with a description of where to obtain it, so schema coverage is 100%. The tool description does not add further parameter meaning, 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 clearly states the tool provides model analysis for a match, specifically predicted win probability, the model's thesis, and key factors. This distinguishes it from sibling tools like get_match_score or get_match_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 implies use for obtaining model analysis but does not explicitly state when to use it over alternatives or mention exclusions. The ULTRA plan requirement is a prerequisite, not usage 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 mark it as read-only, idempotent, and non-destructive. The description adds that it requires the PRO plan, an access constraint not covered by annotations. It also clarifies the event categories, but doesn't discuss ordering or pagination behavior beyond what the schema's limit parameter implies.

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

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

The description is a single concise sentence with an added access constraint, immediately front-loading the tool's purpose. No redundant words.

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

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

With an output schema present, return values need not be described. The description covers the event types and the PRO plan requirement; combined with parameter descriptions and annotations, the tool is fully contextualized for a straightforward read-only operation.

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 contains descriptions for both parameters (100% coverage), so the description adds no additional semantic value for match_id or limit. The baseline score of 3 applies as the schema sufficiently documents parameters.

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

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

The description clearly states the tool provides a timeline of events for a match, listing specific event types (breaks, games won, sets won, momentum runs). This differentiates it from sibling tools like get_match or get_match_score, which likely provide summary or score data.

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

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

The description provides context that this tool is for timeline events, but does not explicitly instruct when to use it over alternatives. There is no mention of when not to use it or which sibling tool to choose for other needs, so guidance is implied rather than explicit.

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

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

The annotations already indicate a safe read-only, idempotent operation. The description adds meaningful context beyond the annotations by specifying the PRO plan requirement and detailing the output structure (bid, ask, mid, implied probability). This provides useful operational context without contradicting 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 a single, front-loaded sentence that conveys the essential purpose and output format, then adds the PRO requirement. Every word earns its place with no redundancy or fluff.

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

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

For a simple read-only tool with a fully documented schema and an output schema, the description is complete: it explains the market type, the per-player probabilities, the pricing components, and the access requirement. No critical information is missing for an agent to select and invoke the tool correctly.

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

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

The input schema already has 100% parameter coverage, describing match_id and limit with defaults and constraints. The description does not add additional parameter semantics beyond that, 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 clearly states the tool returns match-winner market prices with implied probability per player, bid, ask, and mid. This goes beyond a tautology and distinguishes it from sibling tools like get_match and get_match_score, which focus on other match data.

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 retrieving odds on a specific match, and the mention of 'Requires the PRO plan' is a useful precondition. However, it does not explicitly state when to use this tool versus alternatives like get_match or get_upcoming_matches, nor does it mention exclusions or when not to use it.

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 valuable context about latency ('fastest, lowest-latency read') and currency ('Current score'), which goes beyond the annotations. However, it doesn't discuss edge cases like invalid match IDs or real-time update behavior, which are partly covered by the output 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?

The description is two concise sentences, front-loaded with the purpose and followed by usage guidance. No wasted words; 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, one-parameter read-only tool with comprehensive annotations and an output schema, this description is complete. It states what it does, when to use it, and the schema covers the parameter source. No additional context is necessary.

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 description for match_id is 100% covered, explaining it is 'as returned by get_live_matches, get_upcoming_matches or get_recent_results.' The tool description adds no extra parameter meaning beyond the schema, so the baseline of 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 clearly states the tool's function: 'Current score for one match'—a specific verb and resource. It also differentiates from siblings by highlighting it as the 'fastest, lowest-latency read' and specifying the use case, which distinguishes it from tools like get_match or get_archive_match.

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 explicitly says when to use it: 'Use this when you only need the score and already know the match id.' This implies when not to use it, but it does not explicitly name alternative tools, so it falls just 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.

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

Beyond the annotations (read-only, open-world), the description discloses that measured statistics coverage varies by tour, absent fields are omitted rather than zero-filled, and the two families are deliberately kept separate. These are nuanced behavioral details not available from annotations alone.

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. Each sentence contributes meaningful detail—families, coverage variance, omission behavior, and access requirement—with no redundant filler.

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

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

An output schema exists, so the description need not enumerate return fields. It covers the important contextual aspects: match scope, in-play/final status, data families, coverage variability, omission policy, and plan requirement, making it complete for the tool's complexity.

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 fully documents the single match_id parameter with a description. The tool description adds no extra parameter semantics beyond confirming it applies to 'one match,' so it meets the baseline for 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 tool provides statistics for one match and distinguishes the two data families (DERIVED vs MEASURED), making the resource and intent unambiguous relative to sibling tools like get_match_score or get_match_analysis.

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 use for retrieving match statistics and notes the ULTRA plan requirement, giving clear context. However, it doesn't explicitly state when not to use alternative tools, so it stops short of full alternatives guidance.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints, so the safety profile is clear. The description adds a meaningful behavioral trait by noting 'cached stats,' which alerts the agent that the data may be cached and not real-time. This goes beyond what annotations state, providing useful context for freshness expectations.

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, efficient sentence that front-loads the core purpose ('One player's profile') and then lists key attributes. Every word earns its place, with no redundancy or filler.

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

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

The tool is simple (one parameter, no nested objects), has a full output schema, and clear annotations. The description covers what the tool returns at a high level, which is sufficient for an agent to understand the tool's scope. Missing usage guidance is a separate dimension (scored low), but overall completeness relative to complexity is high.

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 covers 100% of parameters, and the player_id description 'Player id, as returned by search_players' adds practical guidance on where to obtain the id. The tool description itself does not add further parameter detail, but the schema is already sufficient, meeting the baseline for schema_description_coverage > 80%.

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 purpose: retrieving a single player's profile, with a specific list of attributes (ranking, country, handedness, date of birth, cached stats). This is specific and distinct from sibling tools like search_players or get_archive_career, though it does not explicitly name 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?

The description implies usage when a player's profile is needed but provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or edge cases, leaving the agent to infer context from the tool name and sibling list.

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

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

Beyond the annotations (readOnlyHint, idempotentHint), the description adds critical behavioral details: the 'never one dated after it' constraint, per-system semantics (rank+points vs rating), and the ITF/UTR history start date. This provides substantial context for expected behavior and data availability.

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 four sentences, front-loaded with the core behavior, and every sentence provides unique value: historical nature, contrast with current data, system-specific behavior, and plan requirement. No redundancy or fluff.

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

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

The description covers the tool's purpose, key date logic, system variations, data history start, and access requirement. With an output schema present, the description does not need to explain return values, and it provides sufficient context for an agent to select and invoke this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying the as_of semantics ('newest record in force ON OR BEFORE as_of — never one dated after it') and explaining system-specific differences, which enriches the parameter meaning beyond the schema 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 retrieves point-in-time ranking records for specific players, scoped by system and as_of date. It explicitly contrasts with current rankings ('Every other ranking field in this API is the CURRENT value... this is the historical answer'), distinguishing it from sibling tools like get_rankings.

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 clearly implies when to use this tool: when historical, point-in-time rankings for specific players are needed. It notes the historical nature and requirements (ULTRA plan), and implies alternatives for current data, but does not explicitly name alternative tools or state 'when not to use'.

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

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description reveals row-level behavior: 'player_name as published and a null player_id for players outside our roster, so the table has no silent holes.' It also discloses data depth (ATP/WTA deep history vs ITF start date) and PRO plan requirement. This is meaningful added context, though not every edge case is covered.

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?

Five short sentences, each carrying distinct information: primary purpose, row behavior, data availability, alternative tool, access requirement. No filler or repetition. Front-loaded with the main action.

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 listing tool with a well-described schema and output schema present, the description covers purpose, usage, alternatives, data caveats, row semantics, and access. Nothing critical is missing; the explicit alternative and PRO plan note make it fully contextual.

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

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

The input schema already provides 100% parameter descriptions, including the as_of semantics and system enum. The description doesn't add parameter details beyond what the schema contains, so baseline 3 is appropriate; no gaps to compensate.

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: 'The FULL published ranking table in rank order for one system' – clearly stating this tool lists complete rankings for a chosen system. It explicitly contrasts with get_player_rankings, distinguishing its scope as the full table rather than point-in-time records for specific 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?

Provides explicit when-to-use guidance: 'For point-in-time records of SPECIFIC players use get_player_rankings' directly names the alternative. Also gives context on data availability (ITF circuits begin 2026-07-29) and access requirements ('Requires the PRO plan'), which helps the agent decide if the tool is appropriate.

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, openWorldHint, idempotentHint, and non-destructive. The description adds the plan requirement (BASIC or History) and the 'recently completed' scope, which is useful behavioral context. However, it does not describe data freshness limits, response format, or any quirky behavior beyond that, so it adds modest value beyond 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 three short sentences, each earn their place: purpose, filterable dimensions, and access requirement. It is front-loaded with the most important information (what the tool returns) and contains no redundant or salesy language.

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?

Given the rich schema (6 parameters, all described, no required) and the presence of an output schema, the description covers the essentials: what is returned, filter capabilities, and access plan. It does not specify how far back 'recent' goes, but this is a minor gap for a list tool with thorough structured metadata. Overall it is sufficient for agent decision-making.

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

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

Schema description coverage is 100%, so the parameters are already well-documented. The description adds a grouped mention of filters ('tour, player, nationality and play date') but does not introduce meaning beyond the schema. It does not clarify ambiguous behaviors like 'recent' boundaries or the exact semantics of play date ranges.

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 returns 'recently completed tennis matches with final scores and winners,' which specifies both the resource and the data included. It distinguishes itself from live/upcoming sibling tools through 'recently completed,' though it does not explicitly contrast with archive tools like get_archive_match or search_archive_matches.

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 context that this is for recently completed matches, which implies when to use it versus live or upcoming match tools. However, it does not explicitly mention alternatives or exclusions (e.g., 'use get_live_matches for live scores'), and the boundary between 'recent' and 'archive' is undefined. The plan requirement adds a condition but not usage guidance relative to 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 readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds value by revealing the return fields and the caveat 'where curated', implying some fields may be missing for certain tournaments. This extra context about data completeness 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?

The description is one tight sentence with an em-dash pivot, front-loading the key purpose ('One tournament by its stable id') and adding terse, relevant details about id source and fields. 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 simple single-parameter read tool with a detailed output schema, robust annotations (readOnly, idempotent, openWorld), and a well-documented parameter, the description is fully adequate. It covers id source, return fields, and the 'where curated' caveat, making it complete for the tool's context.

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, and the schema already states tournament_id is 'Stable tournament id, as returned by search_tournaments or carried on a match as tournament_id'. The description reinforces 'stable' and 'carried on match objects', but adds little beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states 'One tournament by its stable id', specifying the resource (tournament) and retrieval verb implied by 'get'. It distinguishes from sibling search_tournaments by emphasizing the stable id and its source on match objects, and enumerates returned fields (name, tour, surface, indoor, etc.).

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 implicitly tells when to use this tool: when you already have a stable tournament_id, especially from match objects or search_tournaments. However, it does not explicitly exclude alternatives or state when not to use it, leaving some inference to the agent.

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

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

The annotations already declare this as a read-only, idempotent, non-destructive operation. The description adds that the returned matches are 'scheduled to start soon' and include player and tournament information, providing minimal additional behavioral context beyond the annotations. It does not discuss date-range defaults or result volatility.

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 immediately states the tool's purpose and output fields. It contains no redundant information and is easy to parse.

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 list tool with six optional parameters and an output schema, the description is mostly sufficient. It doesn't explain the default time window for 'soon' or clarify the relationship with get_fixtures, but the schema and annotations cover most operational details. Overall adequate but with minor gaps.

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

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

The schema provides 100% coverage of all six parameters with detailed descriptions, including types, enums, and constraints. The tool description adds no parameter-specific semantics, so it does not enhance what is already in the schema. Baseline of 3 is appropriate for high 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 tool lists upcoming tennis matches and includes players and tournament in the output. The verb 'List' is specific and the resource is well-defined, distinguishing it from live and past-result tools. However, it does not explicitly differentiate from the sibling get_fixtures, which could overlap.

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 that this tool should be used for retrieving future scheduled matches, but does not explicitly state when to use it over alternatives like get_fixtures or get_live_matches. No exclusions or alternative recommendations are provided, leaving the agent to infer usage from the name and description.

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 a safe read-only operation, but the description adds valuable context: the archive ends on 2022-12-31, results are winner/loser-shaped with final score and seeds/ranks at match time, and a plan requirement is disclosed. This enriches the agent's understanding beyond the defaults.

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

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

Four sentences, front-loaded with the core action ('Search the results archive'), followed by scope, example, transition to sibling, and plan requirement. No unnecessary words; 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?

With a full output schema (noted as present), the description needn't explain return values. It covers purpose, scope, temporal boundary, usage example, plan requirement, and handoff to a sibling tool. This is complete for a search tool with seven optional, well-documented parameters.

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 covers all parameters with descriptions, so the baseline is 3. The description adds little specific parameter detail beyond the schema; the time-range context for 'from'/'to' is implicit in the archive's date range, but no explicit param-level guidance is given beyond the schema.

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

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

The description clearly identifies the tool as searching the results archive for completed matches from 1968–2022, covering ATP/WTA, main draws, qualifying, and ITF/futures tiers. It distinguishes itself from siblings like get_recent_results by explicitly naming the archive's end date and where the sibling takes over.

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?

Provides an explicit use case ('historical questions ("Borg's Wimbledon finals")') and states the boundary between this tool and get_recent_results ('where our own results (get_recent_results) begin'). Also mentions the required plan (BASIC or History), giving clear guidance on when this tool is appropriate.

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, idempotent, and non-destructive behavior. The description adds valuable context: the fields returned, the historical time range, and the distinction between corpus person ids and roster ids. However, it does not mention rate limits or pagination behavior beyond the schema's limit parameter, so a perfect score is not warranted.

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, no redundancy. The first sentence front-loads the core resource and attributes; the second adds id semantics and a sibling alternative. 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?

With an output schema present, the description doesn't need to explain return values. It covers the essential context: time range, id type, and plan requirement. Minor omission: no mention of result ordering or that the query is a partial match (though the schema example implies it), which prevents a 5.

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

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

The input schema fully describes all three parameters with types, enums, defaults, and examples. The description adds no additional parameter-level detail beyond what the schema provides, 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 clearly states the resource ('the people of the results archive (1968–2022)') and the specific attributes returned (hand, date of birth, country, height, career-high rank). It distinguishes from sibling tool search_players by explicitly noting the archive scope and the difference between corpus person ids and roster ids.

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?

Provides explicit guidance: 'for current players use search_players' and clarifies the id namespace. It also mentions the plan requirement as a precondition, which helps the agent decide when to invoke this tool. This is a strong alternative-identification.

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 read-only and safe behavior. The description adds value by stating the return fields (id, country, ranking, tour) and recommending using the id with get_player, which goes beyond the annotations without contradicting 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 three short, front-loaded sentences with no redundant information. Every sentence adds value: what it does, what it returns, and how to use the result.

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?

Given the tool's simplicity, the presence of an output schema, and strong annotations, the description is sufficiently complete. It could explicitly state that it searches current players (not archive), but the sibling context and return fields imply this.

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 100% coverage, fully documenting both 'query' and 'limit'. The description does not add any parameter-level meaning beyond the schema, 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 the tool searches tennis players by name, with a specific verb and resource. It also mentions the return fields and links to get_player, distinguishing it from other search tools like search_tournaments or search_archive_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?

The description provides clear context: use this tool to find a player ID, then use that ID with get_player. It does not explicitly mention exclusions or alternatives, but the purpose is well-defined and actionable.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral context by explaining that results include surface, indoor, host city/country, and category 'where curated,' which sets expectations about data completeness. This goes beyond simple scoping.

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, front-loaded with the primary verb and object. It efficiently conveys the tool's purpose, the stable ID context, and the returned fields without 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?

Given the tool's simplicity, an output schema, rich annotations, and fully documented parameters, the description is complete. It explains the catalogue's role, the nature of the ID space, and the curated return fields, giving an agent sufficient information to invoke the tool correctly.

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

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

The input schema provides full descriptions for all three parameters (tour, limit, query), achieving 100% coverage. The description adds minimal parameter-specific value, only hinting that query relates to tournament name via 'tournament catalogue.' With schema coverage this high, a 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 opens with 'Search the tournament catalogue,' a specific verb plus resource that clearly states the action. It further distinguishes the tool by explaining this is the stable id space that match objects carry as tournament_id, setting it apart from sibling search tools like search_archive_matches or get_tournament.

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: when you need to search the tournament catalogue, especially to resolve tournament IDs referenced by matches. It provides clear context but does not explicitly state when not to use it or name alternative tools, 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.