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?

The description adds behavioral context beyond the annotations by stating the ordering (earliest first), the forward-looking scope, and the free-plan availability, complementing the read-only, idempotent, non-destructive hints. However, it falsely claims filterability by player and date when the schema only accepts tour and limit, which undermines accurate behavior disclosure.

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

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

The description is compact and front-loaded with the core purpose, with the use case and access note following efficiently. Minor redundancy ('the forward schedule' restates 'upcoming') and the inaccurate filter phrase prevent a perfect score.

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 input schema fully documents the two parameters and an output schema exists, so parameter semantics and return format are covered. The description supplies ordering and access context but lacks differentiation from the overlapping sibling get_upcoming_matches and includes an unsupported filter claim, leaving an agent with a notable gap.

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

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

Schema description coverage is 100%, so the baseline would be 3 even without additional parameter info in the description. But the description actively misrepresents the parameter surface by claiming player and date filters that do not exist in the schema; only tour and limit are supported. This misleading information makes the description counterproductive for parameter understanding.

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 tool returns upcoming scheduled tennis fixtures in chronological order ('earliest first'), clearly identifying a forward-looking read operation. However, it claims filtering by player and date, which the schema does not support, and it does not differentiate from the similarly named sibling get_upcoming_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 an explicit use case ('what is on this week') and notes that it works on the free plan with no card needed, which is useful access guidance. It does not mention alternatives or exclusion conditions, 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?

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 carry the safety profile (readOnlyHint, idempotentHint, destructiveHint, openWorldHint), and the description adds genuinely useful context beyond them: coverage scope, live-score return content, and notably the FREE-plan access constraint ('no card needed'), which is a real-world entitlement signal annotations do not express. The statement 'currently in progress' aligns with and reinforces openWorldHint without contradicting it.

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 short sentences, each earning its place: what it does, what it covers, when to use it, and cost-of-use. The core verb+resource is front-loaded, and there is zero filler or schema repetition.

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

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

Given rich annotations, a fully self-documenting input schema, and an existing output schema (so return values need no explanation), the description is near-complete: purpose, tour scope, use case, and pricing are all covered. The only minor omission is explicit routing to sibling tools for non-live needs, which is a usage-guidelines nicety rather than a blocking gap.

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

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

Schema description coverage is 100%, so the schema fully documents all four parameters including the tour enum, limit bounds, player id array, and the IOC-vs-ISO country-code nuance. Per baseline, the description need not repeat parameter detail, and it doesn't — no added param semantics, but none required.

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

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

The description opens with a specific verb and resource — 'List tennis matches currently in progress, with live scores' — and pins the scope to five named tour levels (ATP, WTA, Challenger, ITF, juniors). It clearly reads as the live variant next to siblings like get_upcoming_matches, get_recent_results, and get_archive_match, so an agent can distinguish it without opening schemas.

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

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

'Use this for "what tennis is on right now"' is an explicit use-case statement that tells the agent when to invoke the tool. It provides clear context, though it stops short of naming alternatives or stating when-not-to-use (e.g., upcoming fixtures or finished matches belong elsewhere).

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, so the description correctly avoids repeating that. It adds valuable context about plan tiers: market prices are only on PRO and model analysis on ULTRA, and it works on the FREE plan without a card. This goes beyond the annotations by disclosing access-level limitations and feature availability, which is helpful for an agent deciding whether this tool meets the user's needs.

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, with the core purpose and contents front-loaded in the first sentence. The second sentence adds plan-tier information without unnecessary detail. Every word earns its place, making it highly efficient and easy to scan.

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

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

Given the tool's simplicity (one parameter) and the presence of an output schema, the description does not need to explain return format. It covers the core behavior and plan limitations. It could be slightly more complete by explicitly mentioning alternatives or edge cases, but overall it provides sufficient context for an agent to call the tool correctly and understand what it returns.

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

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

The schema fully documents the single parameter match_id, including its type and source (from other match-listing endpoints). The description adds no additional parameter guidance, but with 100% schema coverage, that is acceptable per the baseline of 3. No extra semantics 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 retrieves full detail for one match by id, listing the specific fields included (players, score, surface, round, status). This differentiates it from sibling tools like get_match_score or get_match_events, which focus on narrower aspects, so an agent can easily identify this as the comprehensive match lookup.

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 full match detail is needed, but it does not explicitly contrast with alternatives such as get_match_score or get_match_events, nor does it state when not to use this tool. There is no guidance on choosing between this and the many specific match-related siblings, leaving the agent to infer the appropriate context.

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

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

Annotations already cover read-only and idempotent behavior. The description adds meaningful behavioral context beyond the annotations: the ULTRA plan requirement and the empty-result condition when has_analysis is false. This helps the agent avoid unnecessary calls.

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 with no filler. The core purpose is front-loaded, followed by access requirements and an actionable precondition. Every sentence earns its place.

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

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

For a read-only, single-parameter tool with a full input schema and an output schema, the description covers all non-obvious context: plan requirement, the has_analysis prerequisite, and the empty-result case. Nothing critical is missing.

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

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

Schema coverage is 100%, and the only parameter, match_id, is already fully described with source endpoints. The description adds no new parameter-level detail, 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?

Description states a specific verb/resource ('Model analysis for a match') and lists concrete contents: predicted win probability, model's thesis, and key factors. This clearly distinguishes it from sibling tools like get_match_odds or get_match_statistics, even without naming them.

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

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

The description provides clear context and a strong precondition: 'Requires the ULTRA plan' and 'Match rows carry has_analysis — check it first.' It also implies when not to call ('a match with no thesis or profile has nothing to return'). It does not explicitly name alternative tools, but the usage boundary 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 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?

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description correctly adds context beyond them: the PRO plan requirement and the empty-result behavior when no market is mapped. This gives the agent practical expectations 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?

Two dense sentences with no filler. The core purpose is front-loaded, followed by the most important usage caveats, making every sentence valuable.

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 lookup with a rich output schema, the description covers prerequisites (PRO plan), preconditions (has_market), and empty-result behavior. Nothing essential is missing for an agent to call and interpret 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?

Input schema covers both parameters fully (match_id and limit with bounds/default), so the description does not need to add parameter details. It contributes only indirectly by explaining the match-level has_market precondition, which is not a parameter semantic.

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 exactly what the tool returns: match-winner market prices with implied probability per player and bid/ask/mid. This precise scope clearly distinguishes it from sibling tools like get_match_score or get_match_analysis, which cover different 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?

It gives clear context for when to call the tool by requiring the PRO plan and instructing the agent to check has_market first. It does not explicitly name alternatives or exclusions, but the precondition guidance is enough to route correct usage.

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, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond that: it promises low latency ('fastest, lowest-latency read') and mentions the plan requirement (FREE plan, no card needed), which are not in annotations. This is meaningful addition without 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 concise sentences with no filler. The first sentence establishes the core purpose and a key differentiator (speed). The second provides the usage condition and a plan constraint. Everything earns its place, and the most critical info is front-loaded.

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

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

For a simple single-parameter read with an output schema present, the description covers the essential context: what it does, when to use it, and a plan constraint. It doesn't mention edge cases (e.g., match not found, stale data), but these are typically not required for such a lightweight read and are likely handled by the API response schema. Slightly more detail about the response format could be added, but it's not critical given the output schema exists.

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 provides a thorough description for match_id, including valid sources. Schema description coverage is 100%, so the description adds no extra parameter semantics. It doesn't repeat or enhance the parameter documentation, which is acceptable given the schema's completeness. 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 verb and resource: 'Current score for one match' – a specific read operation. It also distinguishes itself from siblings by highlighting 'fastest, lowest-latency read', implying it is the lightweight option compared to tools like get_match or get_match_events. This gives an agent a clear sense of what it does and how it differs.

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 'Use this when you only need the score and already know the match id', which provides a clear condition for selection. It also notes it works on the FREE plan, which is a practical constraint. It doesn't name alternative tools explicitly, but the 'only need the score' phrasing implicitly steers away from richer tools. This is strong guidance, though not exhaustive.

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 mark the operation read-only, idempotent, and non-destructive. The description adds value beyond that by disclosing that stats are cached and that no payment card is needed on the FREE plan, which gives the agent useful behavioral and access 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?

The description is two concise sentences with no filler. The core purpose is front-loaded, and the additional FREE plan note is relevant and quickly actionable.

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-only tool with an output schema and rich annotations, the description is sufficient. It explains the profile contents, notes cached data, and clarifies plan availability, leaving no critical gap for an agent to call it correctly.

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

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

Schema description coverage is 100%, with player_id documented as returned by search_players. The tool description does not add extra parameter detail, so baseline 3 is appropriate since the schema carries the burden.

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 and lists specific fields (ranking, country, handedness, date of birth, cached stats). This distinguishes it from siblings like get_player_rankings or search_players, which serve different purposes.

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 the tool is for fetching a single player's profile and notes it works on the FREE plan, but it does not explicitly state when to use this over alternatives like search_players or get_player_rankings. The schema adds that player_id comes from search_players, providing some routing context.

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 establish the tool as read-only, open-world, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations by disclosing the plan requirement and clarifying that results are final-score winners for completed matches. This gives agents a better sense of what to expect 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 two sentences with no filler. It front-loads the core purpose, then adds filter capability and the access requirement. Every sentence earns its place and the structure is easy to scan.

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

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

The description is complete for this tool's complexity. The schema covers all parameter details, output schema exists so return structure need not be repeated, and annotations cover the safety profile. The description covers scope, result contents, filters, and plan requirement, leaving no critical gap for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already fully documents all six parameters, including formats, enum values, defaults, and limits. The description only restates high-level filter dimensions (tour, player, nationality, play date) without adding new parameter-level meaning. Baseline 3 is appropriate given the schema carries the detailed semantics.

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

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

The description clearly identifies the resource as recently completed tennis matches with final scores and winners. Combined with the tool name, an agent immediately knows it returns a list of recent completed results. This naturally distinguishes it from live, upcoming, and archive match tools.

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

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

The description provides clear context: use this for recently completed matches that have final scores and winners, with optional filters. It also states the required BASIC or History plan, which is a useful access prerequisite. It does not explicitly name sibling alternatives like get_live_matches or get_upcoming_matches, but 'recently completed' strongly implies the boundary.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful context beyond that: 'Works on the FREE plan (no card needed)' and the data-quality nuance that some fields are included 'where curated.' This helps with access and expectations in a way annotations do not.

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 uses three short sentences with the central purpose first, then return fields, then the plan note. It is efficient and front-loaded, though some of the field list could arguably be left to the output schema.

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 one well-specified parameter, clear source for the ID, plan info, and visible output schema, the description is complete enough for an agent to invoke the tool correctly. A small gap is that it does not describe the behavior when a tournament_id is missing or not found, but that is a minor omission.

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

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

Schema coverage is 100% for the single parameter, so the description has no burden to document the parameter. It only repeats what the schema says ('stable tournament id', carried on match objects) without adding format, validation, or additional semantic detail.

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 plainly states the verb ('stable id') and resource ('tournament'), explains where the ID comes from, and lists the fields returned, distinguishing it from sibling tools like search_tournaments. An agent can immediately understand this is a single-entity fetch, not a search.

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

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

The description gives clear context for when to use it: you have a stable tournament_id, e.g., from a match object. The input schema adds that the ID can also come from search_tournaments. It does not explicitly tell the agent to use search_tournaments instead when only a name is known, but the intended use is easily inferable.

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 establish read-only, non-destructive, and idempotent behavior, so the description's burden is lighter. It adds useful context about the FREE plan eligibility and that results are 'soon'-based, but does not detail freshness, time-window defaults, or how 'soon' is bounded.

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

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

Three short sentences with no filler: the primary behavior is front-loaded, followed by concrete use cases and a plan-eligibility note. Every sentence contributes value.

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

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

For a read-only list tool with a rich output schema and fully documented parameters, the description is near-complete. It could clarify the temporal meaning of 'soon' or the relationship to get_fixtures, but the available schema and annotations cover most operational needs.

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 all six parameters are already documented. The description does not add parameter-level semantics beyond what the schema provides, keeping it at the baseline.

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

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

States a specific verb ('List'), a clear resource ('tennis matches scheduled to start soon'), and the included information (players, tournament, start time). The stated use cases ('who plays next', 'find a match id before it starts') also situate it relative to the broader tool family, making its purpose 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?

Explicitly says when to use this tool: for upcoming-match discovery and obtaining a match id before start. It does not name sibling alternatives or state when not to use it, so it stops short of full 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 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, openWorldHint, idempotentHint, and non-destructive intent, so the description does not need to restate safety. It adds useful context beyond the annotations: the free-plan/no-card requirement and the get_player follow-up, and nothing contradicts the annotations.

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

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

Three short sentences with no filler: purpose, output fields, follow-up workflow, and access constraint are each given in one line. The key action and result are 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 full schema documentation, safe-read annotations, and an output schema, the description is mostly complete. It could slightly improve by noting whether it searches only current players vs archive players, given the sibling search_archive_players, but the core workflow is fully covered.

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 query parameter is well described with an example ('alcaraz'), while limit has min/max and default. The description only restates 'by name' and adds no parameter semantics beyond the schema, so it lands at the baseline.

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 action explicitly: 'Search tennis players by name' and lists the returned fields (id, country, ranking, tour), so an agent knows what the tool does. It is clear, but it does not explicitly distinguish this from search_archive_players, so it misses sibling differentiation.

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

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

It gives concrete workflow guidance: use the returned id with get_player, and it notes the tool works on the free plan, which sets expectations about access. It does not explicitly state when not to use it or name alternatives like search_archive_players, so it falls short of fully explicit routing.

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

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

The annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is well covered. The description adds genuinely useful behavioral context beyond annotations: the 'stable id space' relationship, the caveat that some fields are returned only 'where curated,' and the access note about working on the FREE plan.

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

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

Three sentences with no filler. The core action and resource are front-loaded, the return data is summarized in the second sentence, and the access note is a compact, useful addition. 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?

Given a moderate 3-parameter tool, full schema coverage, a present output schema, and rich annotations, the description covers the essentials: purpose, stable ID semantics, return fields, data caveats, and access requirements. It could mention ordering or pagination behavior, but the output schema and parameter constraints already cover the return structure and limits, so little is missing.

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

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

Schema description coverage is 100%, so the parameters (tour, limit, query) are already fully documented with defaults and constraints. The description adds minimal parameter-level meaning beyond saying this is a search; it does not describe query syntax or how tour filtering interacts with the catalogue, but the schema carries the full semantic load, so a 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 opens with a specific verb and resource: 'Search the tournament catalogue.' It goes beyond a generic label by defining the catalogue as the stable id space carried by match objects as tournament_id, and it lists the returned attributes, making the tool's purpose concrete and distinguishing it from get_tournament and 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 clear context: this is a catalogue search suitable for resolving/match tournament IDs, and it notes the FREE plan eligibility. It does not explicitly mention when to prefer get_tournament or another sibling, but the stable-id-space explanation strongly implies the intended use case, so the guidance is clear though not exhaustive.

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