livetennisapi-mcp

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 and idempotentHint, so the description's main contribution is the ULTRA plan requirement. It does not add details about rate limits, data freshness, or other behavioral traits 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?

Two sentences: first states output, second states requirement. Concise and front-loaded. Could improve by moving requirement earlier but overall efficient.

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 presence of an output schema, the description does not need to detail return values. It adequately covers purpose and requirement but lacks usage context and behavioral details. Adequate for a simple read-only 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?

With 100% schema description coverage, baseline is 3. The description adds where to obtain match_id (from get_live_matches, etc.), which provides helpful context but is not critical.

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?

Description clearly states it provides model analysis including predicted win probability, thesis, and key factors. However, it does not explicitly differentiate from sibling tools like get_match_odds or get_match_score, though the content is distinct.

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

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

No guidance on when to use this tool vs alternatives like get_match or get_match_odds. The ULTRA plan requirement is mentioned but doesn't help with selection among 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 indicate readOnlyHint=true, so the tool is safe. The description adds critical behavioral context: requires the PRO plan and lists the types of events included, going 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 a single sentence with clear front-loading of purpose and no wasted words. It effectively communicates the tool's function and a key constraint.

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 presence of an output schema, the description need not detail return values. It adequately explains the event types included and the PRO plan requirement, making it complete for this tool.

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

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

Schema coverage is 100% with descriptions for both match_id and limit. The description does not add extra parameter meaning 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 it provides a timeline of events for a match, listing specific event types (breaks, games won, sets won, momentum runs). This distinguishes it from sibling tools like get_match (full details) and get_match_score (score only).

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies its usage for timeline events but does not mention when not to use it or suggest alternative tools.

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

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

Annotations already declare safe read-only behavior. Description adds value by specifying exactly what data fields are returned (implied probability, bid, ask, mid) and the plan requirement. No contradictions.

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 most critical information (function and prerequisite) is front-loaded.

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

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

Output schema exists to document return values, and the description provides key behavioral context (data types). Combined with strong annotations, the tool is fully documented.

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 has 100% coverage with detailed descriptions for both parameters. The description does not add additional parameter information beyond the schema, so baseline 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?

Clearly states the resource (match-winner market prices) and the data provided (implied probability, bid, ask, mid). Distinguishes from sibling tools like get_match (general info) and get_match_score (score).

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

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

Explicitly notes the PRO plan requirement, which is a key prerequisite. Does not explicitly state when to use vs. alternatives, but the purpose is specific enough that usage context is clear.

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 provide readOnlyHint, idempotentHint, etc. The description adds that it's the fastest/lowest-latency read, which is useful performance context beyond annotations. No contradiction.

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

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

Two sentences, zero wasted words, front-loaded with purpose and usage. Excellent conciseness.

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 one parameter and an output schema, the description is complete. It explains when to use, the speed advantage, and the prerequisite (knowing match ID). No missing critical information.

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% and the schema already provides a clear description for match_id. The tool description does not add new parameter information, 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 the tool gets the current score for one match, emphasizes low latency, and requires knowing the match ID. It distinguishes from siblings by focusing on score-only and speed.

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

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

Explicitly says 'Use this when you only need the score and already know the match id,' which implies when not to use (for other details, use other tools). Does not list alternative names but the guidance is clear.

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?

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and behavior. The description adds that it returns 'cached stats,' implying possible staleness, but does not elaborate on other behaviors like call limits or data freshness guarantees.

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 efficiently conveys the tool's output without unnecessary words. 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?

Given the low complexity (1 parameter, no nested objects, output schema exists), the description sufficiently informs the agent about the returned fields. However, the mention of 'cached stats' is somewhat vague and could be more precise.

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% and the single parameter 'player_id' is described as 'Player id, as returned by search_players.' The description does not add extra meaning beyond what the schema provides, so it meets the baseline for complete schema documentation.

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 one player's profile listing specific fields (ranking, country, handedness, date of birth, cached stats), and the tool name 'get_player' distinguishes it from siblings like 'search_players' 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?

The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. The context from the tool name and sibling list implies usage for retrieving a single player's profile, but no exclusions or comparisons are given.

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 declare readOnlyHint, idempotentHint, destructiveHint. Description adds value by specifying return fields and usage for chaining, which is 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?

Two short sentences with no filler. Every word contributes meaning: purpose, return value, and follow-up tool recommendation.

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 search tool with output schema and comprehensive annotations, the description provides all necessary context: what it does, what it returns, and how to use the result. No gaps.

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

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

Schema coverage is 100% with descriptive parameter definitions. Description adds no new semantic information beyond 'Search tennis players by name', which weakly reinforces the query 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?

Explicitly states 'Search tennis players by name', a specific verb and resource, and lists return fields (id, country, ranking, tour). Distinguishes from sibling 'get_player' by directing use of returned id.

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: use to search, then use get_player with returned id. No explicit exclusion of alternatives, but the chaining pattern is evident from the 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 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.