SportStatsAPI

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral detail beyond the structured fields: result ordering ('most recently seen first') and the fact that results come back grouped (reinforced by limit being per-kind). It stops short of describing pagination or exact return shape.

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

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

A single front-loaded sentence carries purpose, key, returned ids, ordering, and the follow-up tool. Every clause earns its place; only minor tightening is possible.

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

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

With no output schema, the description compensates by stating what is returned (entities plus ids) and in what order. For a two-parameter search tool this is nearly sufficient; only grouping/pagination nuances are left unspecified.

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 both parameters (name substring length bounds, limit default/max) are fully documented in the schema. The description adds only the loose notion of name matching, so the 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?

States a specific verb (Find) and resource (horses, jockeys, trainers) plus the lookup key (by name) and the payload (ids). It does not explicitly contrast with sibling find_* tools, but the entity scope is unambiguous.

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 parenthetical '(for get_runner_form)' signals the downstream purpose of the returned ids, which implies when to reach for this tool. However, there is no explicit when-to-use/when-not or named alternative, so usage is only implied.

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 read-only and idempotent annotations already cover the safety profile, but the description still adds useful context beyond them: the tool is 'Free' and the query also matches official_name (the Wikidata name 'where known'). It does not describe pagination, rate limits, or what happens on empty results, so it is not a full 5.

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?

One tightly written sentence that front-loads the core action and return value, with parenthetical clarifications that earn their place. The final 'Free.' is short but conveys cost information.

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 full schema coverage and annotations, the description is nearly complete: it states the resource, the ID return value, the optional filters, and cost. The only missing pieces are result limits/pagination behavior, which for a search endpoint could matter but is minor here.

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, the baseline is 3, but the description adds genuine meaning for the query parameter by noting it matches 'official_name' in addition to league/country names. That extra matching scope is not stated in 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 states a specific verb and resource — 'Find leagues (competitions) of a sport and their ids' — which lets an agent distinguish this from data-fetching siblings like get_league_facts or get_standings. It does not explicitly name an alternative tool or contrast itself with one, so it falls short of a 5.

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

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

Usage is implied: use it to resolve league IDs, optionally filtered by name or country. However, it never states when to prefer this over get_league_facts, get_standings, or list_sports, nor does it give any exclusions or prerequisites, leaving routing to inference.

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

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

Annotations already declare this a read-only, non-open-world, non-idempotent operation, so the safety profile is covered. The description adds the useful fact that results carry ids, country, venue and leagues (relevant because there is no output schema), but says nothing about limits, permissions, or partial-match behavior.

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

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

A single compact sentence with the action, the lookup key, and the returned fields front-loaded. No filler, no 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 five-parameter search tool with no output schema, the description partially compensates by enumerating return fields, but it omits any explanation of limit/default paging, the language switch, or the league_id filter's role. It is adequate but leaves meaningful gaps for an agent deciding how to call it.

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

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

Schema description coverage is 100%, so all five parameters are documented in the schema itself (lang, name, limit, sport, league_id). The description only echoes the name parameter, adding no syntax, format, or defaulting information beyond what the schema provides.

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

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

The description states a specific verb and resource ('Find teams') plus the identifying input ('by name') and the payload ('ids, country, venue and leagues'). It distinguishes itself implicitly from get_team's singular lookup by being a name-based search, but it never names or contrasts with any sibling tool.

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

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

There is no when-to-use guidance, no stated prerequisites (e.g. that sport must come from list_sports), and no indication of when to prefer get_team or find_leagues instead. The agent is left to infer the search use case entirely from 'by name'.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the scope of the payload (full bout list, method codes, titles) but says nothing about permissions, rate limits, pagination, or failure behavior, so it is adequate but not rich.

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

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

A single front-loaded sentence that opens with the core resource and then enumerates the returned fields compactly. The dense enumeration of method codes is slightly list-heavy but every term 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?

No output schema exists, so the description must carry the return-value burden, and it does so thoroughly by listing the bout fields and result codes. It remains incomplete only on operational behavior (pagination, errors), which is minor for a read-only single-resource lookup.

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 a single parameter at 100% schema coverage, the schema fully documents event_id, including its origin ('from get_boxing_events'). The description adds no additional meaning to the parameter, so the baseline 3 for fully-covered schema applies.

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

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

Names a specific resource (one boxing event) and precisely scopes it ('every bout from the main event down'), which implicitly distinguishes it from the plural sibling get_boxing_events. It stops short of explicitly naming that sibling or stating the distinction, so a 4 rather than a 5.

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

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

The description contains no when-to-use guidance, prerequisites, or comparison to alternatives such as get_boxing_events or get_boxing_fighter. The only workflow hint ('from get_boxing_events') lives in the schema, not the description, so the description itself offers no routing 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 cover the safety profile (readOnlyHint, idempotentHint), so the bar is lower. The description adds real value beyond them: the upstream source is Wikipedia and the caller is obligated to credit attribution, plus the implicit last/current-year data window. It stops short of describing pagination or rate/coverage 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?

Two dense sentences, with the resource, scope and returned fields front-loaded before the cross-tool pointer. The standing-champions sentence is slightly tangential to this tool's job, but it is short and serves real routing 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?

With no output schema, the description usefully enumerates the fields a caller receives, and annotations cover the safety profile. Remaining gaps are pagination behavior and the semantics of the status/date filters, which the schema names but does not explain.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters including kind, limit, offset, season, status and date bounds. The description only restates the card vs. title-fight distinction and the default season, adding no syntax or filtering nuance beyond the schema — the baseline 3 applies.

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

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

Names a specific verb+resource (boxing events) and pins the scope precisely: last and current year, Wikipedia-sourced, covering both fight cards and world title fights. It also enumerates the returned fields (date, venue, city, status, main-event winner), which separates it from the singular get_boxing_event and the mma/motorsport event siblings.

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

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

The description implies usage (fetching recent boxing events) and does route one adjacent need — current world champions — to get_standings with the boxing sport. But it never says when to pick this over get_boxing_event or a calendar-style alternative, and it gives no exclusions or prerequisites.

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 the safety profile (readOnlyHint=true, openWorldHint=false), so the description needn't restate that this is a safe read. It adds some value by naming the upstream data sources (Wikipedia/Wikidata) and what 'current' means for titles and bouts, but says nothing about rate limits, data staleness, or behavior when both parameters are supplied.

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?

It is a single compact sentence with no filler, which is good, but the compressed '(fighter_id):' colon construction and stacked parentheticals make it feel like shorthand notes rather than a front-loaded statement of purpose. It is efficient without being clearly readable.

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

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

With no output schema, the description correctly enumerates the returned fields, which is the main burden. It remains silent on how many 'latest bouts' are returned, pagination, and precedence when name and fighter_id are both provided, leaving gaps for a two-mode lookup tool.

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

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

Schema description coverage is 100%, so both parameters are already documented as 'fighter code (or number) from a bout or the champions' and 'part of a boxer's name, to find the id'. The description only echoes that dual id/name usage and adds no format or matching semantics beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb+resource (retrieve a boxer, or find boxers by name) and enumerates the attributes returned (birth date, country, height, reach, stance, record, titles, latest bouts), which lets an agent distinguish it from get_mma_fighter and the generic get_player. The telegraphic colon phrasing is a bit odd but the intent is unambiguous.

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 'or find boxers by name' clause implicitly tells the agent to use the name parameter when it lacks an id, which is useful dual-mode guidance. However, there is no explicit statement of when to prefer this tool over sibling lookups such as get_mma_fighter or the name-based find_* tools, so routing is left to inference.

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

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

Beyond the read-only annotations, the description discloses important behavioral limits: unprovable rounds are marked missing with a reason and no ties, pairings are never guessed, and placeholders are only added where the draw tree is proven. This is exactly the kind of integrity and edge-case context an agent 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 front-loaded with what the bracket contains, then proceeds through sport-specific usage and data-provenance rules. It is dense but every clause is relevant; better formatting could improve scanability, but it is not padded.

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

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

With no output schema, the description carries the burden of explaining the return value and does so thoroughly: it describes rounds, ties, legs, aggregates, advancement methods, and provenance. It also explains missing-data behavior, leaving little an agent needs to infer.

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

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

Schema coverage is 100%, so the schema already documents all four parameters. The description reinforces the sport-specific mappings and defaults but adds little beyond the schema, making the baseline 3 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 establishes that this tool returns a knock-out bracket, detailing rounds, ties, legs, aggregate, advancement, and sourcing. It is a precise resource description, but it does not explicitly contrast with sibling tools, which keeps it from a 5.

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

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

It specifies the contexts in which the tool applies: soccer cups and European knock-out phases, tennis draws, and snooker/darts tournaments. It does not name alternative tools or state exclusions, but the sport-by-sport guidance is clear enough for 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description's job is to add content context, which it does: it defines the per-fact payload (type, importance, text), the summary-paragraph aggregation, the allowed languages, and a scope limit ('Facts only, no predictions'). It stops short of stating fact counts, truncation, or fallback behavior when no facts exist.

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 payload shape and ordering promise are front-loaded in the first clause, followed by the fact taxonomy and the sibling comparison. It is dense and largely waste-free, though the fragmentary, semicolon-chained phrasing takes a second read 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?

With no output schema, the description carries the burden of explaining return values and does so well — enumerating fact fields, the summary paragraph, and the 'no predictions' boundary. What remains thin is edge-case behavior (empty results, volume of facts), which is minor for a read-only insights tool.

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

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

Schema description coverage is 100%, so every parameter is already documented, including the de/es/it/fr language set and the match/team/player kinds. The description reinforces the language constraint but adds no syntax or format detail beyond the schema, which is the expected baseline of 3 when the schema does the heavy lifting.

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 resource (ready fact sentences for a match or team) and its ordering (most important first), then enumerates the fact categories it covers. It explicitly distinguishes itself from get_match_briefing and get_team_briefing by noting it returns the same facts 'without the data blocks', so an agent can tell the siblings apart without opening a schema.

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

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

Gives clear selecting conditions: use for a match or team, use get_league_facts for a league (in the kind param), and pick this over the briefing tools when the narrative data blocks aren't wanted. It doesn't spell out exclusions for other siblings like get_summary or get_h2h, so the routing is strong but 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: 'thru and today while live' signals partial in-progress data, cut/withdrawn statuses indicate non-uniform row semantics, and 'holes=true ... (large)' warns that the response can balloon in size.

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

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

A single dense sentence with a semicolon is front-loaded on the payload contents and ends with the optional expansion flag. It is efficient, though the comma-list enumeration makes it heavy to parse at a glance.

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

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

With no output schema, the description carries the burden of describing the return payload and does so thoroughly. It does not cover pagination, auth, or freshness beyond 'while live', but for a read-only lookup keyed by tournament_id it is nearly complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning for the holes flag by specifying that it yields hole-by-hole scores and that the payload is large — useful cost/benefit information the schema does not convey.

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

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

The description names a specific resource (a golf tournament's leaderboard) and enumerates exactly what it contains (position, to par, strokes per round, thru/today, earnings, cut/withdrawn, per-player stats), which clearly separates it from get_golf_tournaments and get_golf_player in the sibling list. It lacks an explicit verb like 'Get' but the resource-and-payload framing is unambiguous.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives. The only routing signal (tournament_id comes from get_golf_tournaments) lives in the input schema, not 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 cover the safety profile (readOnlyHint=true, openWorldHint=false, idempotentHint=false). The description adds useful context about data provenance ('from our leaderboards') and the fields returned, but says nothing about the odd non-idempotent hint, default behavior, or result shape beyond the field list.

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?

It is a single dense sentence that front-loads the primary capability and tacks the alternative lookup mode onto the end. Efficient, though the parenthetical field list makes it somewhat run-on and harder to parse quickly.

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

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

With no output schema, the description does the work of enumerating return content, and it names all three parameter roles. For a read-only lookup tool with full schema coverage this is largely sufficient, though the dual-mode behavior could be spelled out more crisply.

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 schema already documents all three parameters, including that name takes 'part of a golfer's name' and season defaults to the latest. The description reinforces that player_id drives the profile view, but adds no syntax or format detail 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 names a specific resource (a golfer's profile and season results) and enumerates the fields returned (country, birth date/place, PGA rank, events, wins, top 10s, cuts, earnings), plus a secondary lookup-by-name mode. It is clearly distinguishable from get_golf_leaderboard and get_golf_tournaments, though it doesn't explicitly say so.

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 'or find golfers by name' implies a two-mode usage pattern tied to whether you have a player_id or a name, but there is no explicit guidance on when to prefer one mode, no prerequisites, and no mention of alternatives among the many sibling 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?

With annotations already declaring readOnlyHint=true, openWorldHint=false, and idempotentHint=false, the description adds domain-specific behavior: LPGA coverage is schedule-only with no leaderboards, and the leader/winner field is the only leaderboard-adjacent data. It does not cover pagination behavior, but the schema handles that. No contradiction with annotations.

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

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

Three short sentences/fragments, front-loaded with the core resource and return fields, then the key constraint, then the alternative tool. Every part earns its place with no redundant padding.

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

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

For a 7-parameter read-only tool with no output schema, the description lists the return fields and clarifies LPGA limitations, which is important. It omits any mention of default season or pagination defaults, but those are covered by the schema. The description is largely complete.

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 seven parameters are fully documented in the schema. The description adds only 'by date' which is already captured by date_from and date_to. It does not add syntax or format details 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 states the resource (golf tournaments) and scope (PGA Tour and LPGA, by date) and lists key return fields (course, location, purse, status, leader/winner). It distinguishes from get_standings by naming it for the season money list, but does not explicitly name get_golf_leaderboard as the full leaderboard tool, leaving minor ambiguity about that sibling.

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 a clear alternative for a related task: the season money list is retrieved via get_standings with sport golf. It also notes that leaderboards exist for the PGA Tour only, which guides expectations. However, it does not state when-not to use this tool versus get_golf_leaderboard, so no explicit exclusions 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?

Annotations already cover the safety profile (readOnly, not open-world). The description adds real scope disclosure beyond that: 'every meeting in our data (all competitions, no friendlies)' and 'history_from: our data starts there, so say since that date' — a data-coverage limitation an agent would otherwise not know.

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

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

Purpose is front-loaded, but the rest is a dense run-on cramming sports list, output fields, perspective rules, sentence languages, and history_from into one block. Because there is no output schema the content is needed, yet the packing hurts scannability.

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

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

With no output schema, the description carries the return-format burden and does so thoroughly (records, goals, biggest wins, recent meetings, generated sentences). The trailing 'Facts only. Insights feature.' is cryptic and never explained, a minor 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 coverage is 100% so the baseline is 3, but the description goes further: it defines the perspective semantics ('won, drawn and lost from team_a's side; home_team_* fields = team_a'), which meaningfully disambiguates team_a vs team_b beyond the schema's terse 'team code'/'the other team's id'.

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?

Names the specific operation (head-to-head between two teams) and enumerates the exact return content: wins/draws/losses from team_a's side, goals, biggest wins, last 5 meetings. It also carves out tennis explicitly via get_player, so an agent can distinguish this from sibling lookups like get_match or get_team without opening a schema.

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

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

The tennis carve-out ('Tennis: get_player with vs') gives one explicit alternative route, and 'soccer by default' plus the sport list tells the agent which inputs are valid. It lacks a general when-to-use statement, but the head-to-head framing plus the tennis redirect is clear 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 the safety profile (readOnlyHint=true, openWorldHint=false, idempotentHint=false), so the bar is lower. The description adds the ordering convention ("newest first") and the content scope, which is useful, but the trailing fragments "Facts only. Insights feature." are terse and ambiguous rather than informative, and return format/volume is unaddressed.

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?

It is appropriately short and leads with the content description, but the compressed clause-piling and the dangling fragments "Facts only. Insights feature." reduce readability and feel like leftover notes rather than earning their 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 listing tool with no output schema, the description does the work of describing return content (facts, story elements, sentence forms) and ordering, which compensates for the absent output schema. It stops short of describing result volume or pagination, but is close to complete.

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 five parameters (lang, since, sport, league_id, min_importance) are already fully documented in the schema. The description only echoes the language list already present in the schema, adding no new parameter meaning beyond 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 a specific resource (facts about finished matches in a league) and enumerates the concrete content it returns: match story, comebacks, late winners, red cards, runs, table places and zones. It implicitly distinguishes itself from raw siblings like get_matches or get_standings by framing itself as a curated fact/story feed, though it never names those siblings explicitly.

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

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

There is an explicit usage cue: "Use for 'what happened in this league today'" plus a scope marker ("Facts only"). It gives clear context for when to reach for this tool but offers no when-not guidance and names no alternative tools for adjacent needs.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds useful context about payload contents (score, minute/period, TV channels 'where known'), which also flags that channel data may be absent — but it says nothing about freshness or result volume.

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

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

A single front-loaded sentence with no filler; the temporal scope and return contents are stated immediately and nothing is repeated from the 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 no output schema, the description usefully characterizes the return shape (score, minute/period, channels where known), which is exactly what an agent cannot get elsewhere. It is nearly complete for a simple read tool; only edge behaviors like empty results or freshness remain unaddressed.

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 sport (with its 'see list_sports' pointer), lang and league_id are already fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific resource (matches) with an unambiguous temporal scope ('in play right now'), which cleanly separates it from the scheduled/historical siblings like get_matches, get_match and get_match_details. It also names the payload (score, minute or period, TV channels).

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

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

Usage is implied by 'right now' — an agent can infer it should call this for currently active matches rather than completed ones. However, no alternative tool is named and there is no explicit when-not guidance (e.g., use get_matches for fixtures).

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

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

Annotations only cover read-only/open-world hints, so the description carries the real burden and does it well: it enumerates which fields exist per sport, discloses accuracy caveats ('minute null = not known', 'no headers or xG per shot: not in our data'), states temporal availability of editorial content, and warns the consumer not to extrapolate. That is exactly the beyond-schema behavioral context an agent 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?

It is a single run-on sentence of roughly 150 words with semicolon-chained clauses; the vocabulary enumeration for the soccer timeline is long enough to slow scanning. Content earns its place, but formatting does not — bulleted or sentence-split structure would make the sport-specific branches far easier 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?

With no output schema, the description must describe returns and largely does — field lists, event kinds, referee_stats denominators, summary components. Residual gaps are error behavior for a bad match_id and whether the shape varies by sport beyond the soccer/editorial notes, but nothing critical to a correct call 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 already 100%, so the baseline is 3; the description earns an extra point by adding a real caveat not present in the schema — that the editorial summary is English only regardless of the lang parameter. It also corroborates that match_id comes from get_matches and sport from list_sports.

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

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

Opens with a specific resource-and-payload statement: 'One match: teams, score, status, events..., venue, referee', and layers on sport-specific extras (soccer timeline, referee_stats, editorial summary). It is clearly distinct from the plural get_matches, but it never names or rules out the closely-related siblings get_match_details and get_match_briefing, leaving overlap unresolved.

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 statement of when to pick this tool over get_match_details, get_match_briefing, or get_match_briefing's kin that sit right next to it. The only directive is about downstream handling ('Quote them as facts; never add predictions'), which is output etiquette, not tool selection. Availability windows ('only until kick-off and once finished', 'English only (no lang)') hint at constraints but do not 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?

Annotations already declare this as a read-only, non-open-world operation, and the description adds meaningful behavioral context: facts only, no predictions, language support, post-match narrative constraints, and the history_from data boundary. It does not cover permissions or rate limits, but those are less relevant for a read-only briefing tool.

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 front-loaded with the core purpose, but it becomes a long run-on enumeration of content blocks and output variants. Much of the detail is valuable for a tool with no output schema, yet the structure could be clearer and more concise.

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

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

With no output schema and a complex briefing tool, the description is thorough about what the briefing contains, how language and format are handled, and what limitations apply. An agent has enough information to understand the return content and call 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?

Schema coverage is 100%, so the schema already documents lang, sport, format, and match_id. The description adds minor context such as 'any sport but cricket' and language availability, but it mostly repeats what the schema already provides. 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 states a specific resource and scope: a ready briefing for one match, covering all sports except cricket, with detailed content areas. It does not explicitly differentiate itself from close siblings such as get_match or get_match_details, leaving the agent to infer that this is the comprehensive briefing variant.

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 a clear usage cue: 'Prefer this for tell me about this match,' and distinguishes pre-match soccer content from post-match story content. It does not state when to choose get_match_details or get_match instead, so alternatives are only implied.

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 that this is a read-only operation, so the description's added value is in disclosing the available content per sport and the important data-quality rule that unknown injury values are null and must not be guessed. That is meaningful behavioral guidance beyond the annotations, though it does not discuss response size, pagination, or freshness.

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 front-loaded with the core purpose and then packs the sport-specific variants into one dense sentence. It is efficient, though the long enumeration makes it somewhat harder to scan than a short structured list.

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 retrieval tool with fully described parameters and no output schema, the description gives an adequate domain map of what each part can return across sports. The explicit null-handling note for injuries is a valuable completeness detail, though more guidance on sibling selection would make it stronger.

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

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

Schema description coverage is 100%, so the parameters are already fully documented structurally. The description largely restates the sport-specific part values that the schema itself enumerates, adding little semantic detail about formats or constraints beyond what is already 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?

The description clearly states that this tool returns details for a single match and enumerates the sport-specific content types available. It is specific enough to distinguish from broad listing tools, but it does not explicitly contrast itself with siblings like get_match, get_match_briefing, or get_summary.

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

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

Usage is implied: call this when you need deeper match detail rather than a summary or list. However, it does not explicitly say when to use this versus get_match, get_match_briefing, or get_summary, nor does it state prerequisites beyond the schema's note that match_id comes from get_matches.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description goes further, disclosing return content (TV channels by country, highlights video link) and default filtering behavior when no filters are given, which is genuine added 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 core scope statement is front-loaded, but the rest is a dense run-on sentence with deeply nested parentheses that is hard to parse. Information is present but structure is not optimized for quick scanning.

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 12 parameters and no output schema, the description covers the main usage modes and return content adequately. However, given the tool's complexity, edge cases like paging (offset/limit) interaction and multi-filter combinations are left to the schema rather than addressed.

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 every parameter is already documented in the schema. The description reinforces the team_id/status interplay and the date-range fields but adds little syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource (matches – fixtures and results) with clear scope variants: by day/date range, by league, or one team across competitions. It is distinguishable from get_match (single) and get_live_matches (live only), though the boundaries with those siblings are only implied rather than named.

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?

Gives concrete context: no date/team defaults to today (UTC), team_id without dates returns latest results then next matches, and status interacts with the team view (scheduled/finished). It stops short of explicitly naming when to prefer get_live_matches or get_match instead.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds useful return-content context (what details a card/fight includes) but says nothing about auth, rate limits, or behavior when neither optional parameter is supplied, so it adds only moderate 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?

A single dense sentence that front-loads the primary scope (full card) before the bout_id variant. No filler, though the packed field list makes it slightly overloaded.

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

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

With no output schema, the description helpfully enumerates the return fields, which is good. But both parameters are optional (required=0), and the description never says what happens when neither is provided, nor does it frame this against the get_mma_events sibling – a notable gap for a read tool with no output schema.

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 both parameters carry their own descriptions ('event code from get_mma_events: the full card', 'bout code: that fight with its stats'). The description restates the bout_id behavior but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (get) and resource (MMA event/card), and enumerates the returned content (weight class, fighters, winner, method, round, judges' scores, stats), which is unusually specific. The singular 'card' vs the sibling get_mma_events (plural list) is distinguishable by implication, though the sibling is never named explicitly.

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 'or with bout_id one fight' implies the two operating modes, letting an agent infer which parameter selects a full card versus a single fight. However, there is no explicit guidance on when to choose this tool over get_mma_events or get_mma_fighter, and no exclusions or prerequisites.

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 the safety profile (readOnlyHint=true, openWorldHint=false), so the description only needs to add behavior beyond that. It does add that the main event result is present 'once known', which is useful context, but says nothing about paging behavior, result completeness for future cards, 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?

A single dense sentence with the resource and returned fields front-loaded and no filler. It stops just short of a 5 because the field list crowds out any guidance an agent would need for paging.

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

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

With no output schema, the description correctly compensates by naming the return fields, which is the key thing an agent needs here. Remaining gaps (pagination semantics, behavior for cards without a result yet) are minor for a filtered list endpoint.

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 five parameters (limit, offset, status, date_from, date_to) are already documented in structured data. The description's 'by date' phrasing aligns with the date filters but adds no syntax or format detail beyond the schema, making the baseline 3 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?

States a specific verb+resource ('MMA fight cards' returned by date) and enumerates the payload (name, date, status, main event result). It is clearly distinguishable from get_mma_event by the plural 'cards' framing, though it never explicitly names the singular sibling.

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

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

There is no when-to-use or when-not-to-use guidance and no routing to alternatives such as get_mma_event for a single card. 'By date' weakly implies the date_from/date_to filters but leaves usage entirely to inference.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real value beyond that: the coverage window (bouts since 2026, with pre-2026 fights only where Wikipedia/Wikidata exists) and the attribution requirement. This is meaningful behavioral context an agent could not infer from annotations or schema, though rate limits and the significance of idempotentHint=false are unaddressed.

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 body is a single sprawling sentence dense with parentheticals and semicolon clauses, front-loading a long field inventory before the simpler name-search mode. Content is mostly relevant but is neither scan-friendly nor clearly front-loaded, which hinders quick agent parsing.

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

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

With no output schema, the description carries the return-value burden and largely succeeds: it spells out the record breakdown, conditional profile fields (birth date, height, reach, stance, nationality, weight class, team) and pre-2026 history. The gap is the search mode, where it does not indicate whether a name query returns a list of matches or a single record.

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 both parameters are already documented (name = partial name to find the id; fighter_id = code from a bout). Per the rubric, baseline is 3 when the schema does the heavy lifting. The description reinforces the retrieve-by-id mode but adds no syntax or format detail beyond what the schema states.

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

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

The description names a specific resource (an MMA fighter) and enumerates the record fields returned (wins/losses/draws/no-contests, method breakdowns, profile, history). Combined with the sibling set (get_boxing_fighter, get_golf_player, get_snooker_darts_player), the MMA scope is distinguishable. It loses a point for fusing two functions (record retrieval and name-search) into one run-on sentence rather than stating a single clear 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 trailing 'Or find fighters by name' implies a two-step workflow (name to locate the id, id to pull the record), reinforced by the schema note on the name param. However, there is no explicit when-to-use/when-not guidance and no comparison against siblings like get_boxing_fighter. Usage is only implied, matching a 3.

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?

With annotations only declaring readOnly/openWorld/idempotent, the description carries real behavioral weight: it discloses freshness semantics ('summary_as_of', 'absent when not fresh'), an under-18 suppression rule, null-means-not-in-data conventions repeated per data source, attribution requirements for Wikidata values, and counting rules ('retirements counted, walkovers not', 'matches without statistics or that he missed are not listed'). These are exactly the kind of caveats an agent needs before interpreting results.

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?

It is one enormous run-on sentence with semicolon chains, not front-loaded by tier or sport, which makes it hard to scan. The phrase 'null = not in our data' is repeated three times and several clauses restate the same freshness convention, so length is not fully earning its place despite the information density.

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 multi-sport tool with six parameters and no output schema, the description does the heavy lifting of explaining what each sport returns, including season_stats and last_matches shapes. Gaps remain around error behavior for unknown player_id and any rate/attribution limits beyond the Wikidata citation note.

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 largely restates the schema's per-sport meanings for 'vs', 'matches' and 'season' rather than adding syntax or edge-case guidance. It adds marginal clarity by tying 'with matches' to the last_matches payload, but nothing the schema does not already convey.

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 opening clause states a specific resource ('Player profile with summary') and enumerates the content delivered per sport, so an agent can tell it returns a player profile rather than a match or team. Sibling differentiation is weak: the description never says why to use get_player over get_golf_player, get_snooker_darts_player or get_boxing_fighter, leaving overlap with those tools unresolved.

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

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

Usage is only implied by the sport-conditional inventory ('tennis also...', 'soccer also...'), which tells an agent what it will get but not when to select this tool over the player-specific siblings. There are no explicit exclusions or prerequisites such as requiring a player_id from a squad/lineup call.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description still adds useful behavior: data may be absent ('where the feed has it') and result fields exist only 'once settled', disclosing conditional/incomplete payloads, though it says nothing about auth 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?

A single front-loaded sentence opens with the resource and then lists payload contents without filler. Dense but purposeful; mildly over-stuffed with field enumerations that could be trimmed.

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?

There is no output schema, so the description must describe return values, which it does thoroughly, including the two distinct states (pre-settlement card vs. settled result). With annotations covering safety, an agent has enough 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?

With a single parameter at 100% schema description coverage, the schema already documents race_id and its accepted types. The description adds no extra meaning about the id format or how to obtain it, so the baseline 3 applies.

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

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

The description clearly states the tool returns a single horse race card and enumerates the runner fields (number, horse, jockey, trainer, weight, rating, form, prices) plus settled results. It is specific verb+resource, but it never explicitly distinguishes itself from close siblings like get_race_briefing or get_races.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of the alternatives (get_races to discover the id, get_race_briefing for summaries, get_runner_form for a single horse). The only routing hint, 'race code from get_races', lives in the schema, not 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=true and openWorldHint=false, so safety is covered. The description adds meaningful behavior beyond that: the pre-race vs post-race distinction ('after the race the winner, starting price'), the multi-language sentence variant, and a data-quality note ('Facts only').

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

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

A single dense sentence front-loads the core purpose and then lists content. It is information-rich with little waste, though the long semicolon-chained clauses make it slightly run-on.

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

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

With no output schema, the description carries the burden of describing returns and does so thoroughly (pre-race and post-race fields, formatting, languages). Only the usage/alternative-selection guidance is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying that lang produces 'each statement also as a sentence', expanding on the schema's narrower 'language of team, league and country names' wording.

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 and resource ('Ready briefing for one horse race') and then enumerates the exact content scope (field size, distance, going, form figures, strike rates, winner/SP). This is clearly distinguishable from siblings like get_race (raw race data) and get_runner_form (single runner).

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 statement of when to use this versus alternatives such as get_race, get_races or get_runner_form, and no prerequisites or exclusions. The content list implies a comprehensive-briefing use case, but the agent is left to infer that.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real context beyond them: races are UTC-day scoped, default to today, and carry a status life-cycle (NS, live, result_pending, FT, unlisted). It says nothing about pagination behavior or result volume, though the schema covers limit/offset.

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

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

A single dense sentence that front-loads the core scope (a day's races, default today UTC) before the optional filters and the field list. It is a fragment rather than a sentence, but little could be trimmed without losing information.

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

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

With no output schema, enumerating the returned fields (off time, course, distance, going, class, runners, status) is genuinely valuable and fills the biggest gap. What remains unstated is the volume/paging expectation and how this list relates to the singular get_race lookup.

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

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

Schema description coverage is 100%, so the schema already documents date, limit, offset, region and meeting_id fully. The description only adds emphasis on region/racecourse filtering and the meaning of the non-parameter 'status' field, 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?

States a specific resource (horse races) with a scope (one day, defaulting to today UTC) and enumerates the returned fields, so an agent can tell it retrieves a daily race list rather than a single race or a briefing. It does not explicitly name the sibling it differs from (get_race, get_race_briefing), so differentiation must be inferred from the singular/plural split.

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?

"Optionally of one region or racecourse" implies the filtering use case, but there is no explicit when-to-use versus get_race / get_race_briefing / get_racing_stats, and no statement of what happens when no race is scheduled. Usage is implied rather than directed.

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=false, and idempotentHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the data comes from stored results, the lookback windows differ by kind (14/30 days for jockey/trainer, 365 days for course), and exactly what each kind returns. It does not mention rate limits or latency, which keeps it short of 5.

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, and the data-source framing is front-loaded ahead of the per-kind detail. The 'kind jockey or trainer...' phrasing is telegraphic but still parseable and compact for the amount of information conveyed.

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?

There is no output schema, so the description carries the return-value burden and does so thoroughly, enumerating the metrics produced for each kind including sample sizes for the draw bands. It is essentially complete for a two-parameter stats lookup; only cross-tool routing and pagination/limits are absent.

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 goes beyond the schema by unpacking what each kind value actually yields (runs/wins/places/strike rate vs favourite win rate, top jockeys/trainers, draw bands), giving the agent semantic depth the bare enum-like schema lacks.

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

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

The description states a specific resource (racing stats) and precisely enumerates the metrics returned for each kind value, so an agent knows exactly what it gets. It does not name a competing sibling tool, but no sibling in the list appears to overlap with racing stats, so differentiation is implicit rather than 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?

The two kind modes are described well enough that an agent can infer which to use for a jockey/trainer versus a course, but there is no explicit when-to-use guidance, no prerequisites, and no routing to alternatives such as find_race or find_horses. Usage is implied through the kind breakdown only.

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, closed-world, non-idempotent behavior, so the bar is lower. Beyond that, the description adds real behavioral value: results are ordered 'latest first' and it discloses the exact returned fields and derived aggregates (wins, top-three, strike rate). It does not describe failure modes for an unknown id, keeping it at 4.

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

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

A single, front-loaded sentence that leads with the core purpose ('Last runs of a horse, jockey or trainer') before enumerating fields. The dense field list is justified because no output schema exists to carry that information, though it slightly strains readability.

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

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

With no output schema, the description correctly assumes the burden of describing return values, and it does so thoroughly (fields plus aggregate stats). Combined with read-only annotations and a fully covered input schema, an agent has nearly everything needed; only edge-case behavior (unknown id, empty history) is unaddressed.

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 three parameters are already documented, making 3 the baseline. The description reinforces the entity kinds (horse, jockey, trainer) that map to 'kind' and implies the run history governed by 'limit', but adds no format or syntax detail 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?

States a specific verb+resource: it retrieves the last runs (form) of a horse, jockey or trainer, and even enumerates the returned fields. This clearly separates it from the find_* siblings, which locate entities rather than return their history. It stops short of explicitly naming a sibling alternative, so 4 rather than 5.

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

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

Usage is only implied: the description makes clear this returns recent form, but never states when to reach for it versus e.g. get_race or find_horses. The schema's mention of find_horses as an id source hints at the workflow but the description itself gives no when-to-use or exclusion guidance.

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

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

Annotations already declare readOnlyHint=true/openWorldHint=false, so the safety profile is covered. The description adds two genuinely useful facts: the data is sourced from Wikidata and coverage is limited to 'the stored seasons', which tells the agent results may be incomplete. It says nothing about pagination, missing-player behavior, or the name-search result shape.

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

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

A single compact sentence with the primary lookup key (player_id) front-loaded. The semicolon-chained payload list is dense but earns its space by describing return content in the absence of an 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 no output schema, the description carries the return-value burden and does list the returned fields (country, ranking, birth date, titles, finals, latest matches). However, it does not explain what the name-search branch returns, how many results, or how the id/name inputs interact when both are absent.

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 three parameters are already documented, including 'part of a player's name, to find the id'. The description only restates that player_id and name are alternate lookup paths, adding marginal meaning over the schema. Baseline 3 applies.

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

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

The description states the resource (a snooker or darts player) and enumerates the payload it returns, which distinguishes it from the generic get_player and other sport-specific player tools. It never states an explicit verb and leads with the payload rather than the action, but the intent is unambiguous.

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 trailing 'or find players by name' signals a second mode, but there is no explicit when-to-use, when-not, or named alternative (e.g., sibling find_* tools). Usage is only implied from the parameter names.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine substance beyond that: the full-draw ordering (qualifying first, final last), the per-round stat set (seeds, frames/legs/sets won, best of, three-dart averages) and the sport-conditional field (century breaks for snooker only), which tells the agent what to expect in the response for each sport.

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

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

A single dense sentence with no filler, and the primary identification ('a snooker or darts tournament with its whole draw') is front-loaded before the field inventory. The semicolon-separated clause for the sport-specific field is efficient, though the sentence fragment style makes the tool's action slightly less immediate.

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

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

With no output schema, the description carries the return-value burden and does so well by listing what a caller gets back per round and per sport. What remains thin is the operational side: no verb framing, no failure/edge behavior for an unknown tournament id, and no note on whether live or upcoming events are included. For a two-parameter read tool, that is a minor gap rather than a blocking one.

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 both the sport enum values and the tournament_id provenance are already documented in the schema, giving a baseline of 3. The description contributes only indirectly, by showing that 'sport' changes the output shape (three-dart averages for darts, century breaks for snooker), and adds no format guidance for the id itself.

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

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

The description names the resource precisely ('a snooker or darts tournament with its whole draw') and enumerates the payload fields, so an agent can tell this is the single-tournament detail tool rather than the list tool get_snooker_darts_tournaments or get_snooker_darts_player. However, it is a noun phrase with no verb, so it describes the returned entity rather than explicitly stating the retrieval action, and it never names the sibling it contrasts with.

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

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

There is no explicit when-to-use or when-not-to-use statement; the description only implies usage by describing the full draw payload. The one routing clue ('from get_snooker_darts_tournaments') lives in the input schema rather than the description, so the agent must assemble the call sequence itself. Usage is inferable but not stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context not in the structured fields — data comes from Wikipedia and coverage spans the current and last season — but says nothing about result freshness, result caps, or paging behavior beyond what the schema already states.

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 resource and scope; the trailing sentence is a routing hint that earns its place. The first sentence is a dense noun phrase rather than a verb-led clause, which slightly slows parsing but wastes no 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 no output schema, the description helpfully enumerates returned fields (dates, venue, prize fund, winner, final score) and default season scope. For a six-parameter read tool whose schema is fully documented and annotations cover safety, this is close to complete, with only paging/result-limit behavior left implicit.

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 goes further by mapping the abstract 'kind' values to real-world event categories (ranking/invitational for snooker; PDC majors, World Series, Players Championships, European Tour for darts), which helps an agent pick a valid kind without guessing.

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

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

The description names the exact resource (snooker/darts tournaments covering World Snooker Tour ranking/invitational events and PDC majors, World Series, Players Championships, European Tour) and the scope (current and last season), plus the returned fields. It distinguishes itself from get_standings, but does not differentiate from the singular sibling get_snooker_darts_tournament, leaving some ambiguity about list vs. detail.

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 explicitly routes world-ranking queries to get_standings with sport snooker or darts, which is a genuine alternative-tool hint. It gives no explicit when-not guidance or prerequisite conditions beyond that, so it stops short of a full usage contract.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds meaningful behavioral context: summary freshness ('absent when not fresh'), data completeness caveats ('matches_with_attendance of matches_played says how complete'), and attribution requirements ('cite the attribution'). These are valuable disclosures 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 a single enormous run-on sentence packed with semicolon-separated mode descriptions and parentheticals. It is front-loaded with the core purpose, but the bulk is dense and largely duplicates the schema, making it hard to scan and use.

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 complex 16-parameter tool with no output schema, the description covers the key return modes and data-quality caveats, including freshness, completeness, and attribution. It is reasonably complete, though its density and overlap with the schema prevent 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?

Schema description coverage is 100%, so the schema already documents all 16 parameters in detail. The description restates many of the same modes (tour, ratings, top_scorers, player_stats) in prose without adding syntax or format details beyond what the schema provides. 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?

Opens with a specific verb and resource: 'League table of a league,' then enumerates the additional outputs it can return. The core purpose is clear, but the sprawling mode list makes it harder to tell at a glance how it differs from siblings such as get_league_facts or get_bracket.

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 how each mode is selected ('for soccer also...', 'for tennis...') and the schema repeatedly says 'instead of the table,' but it never explicitly states when to use this tool versus alternatives or prerequisites such as obtaining league_id from find_leagues. Usage is inferable rather than clearly guided.

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 safety (readOnlyHint=true, openWorldHint=false), and the description adds genuinely new behavioral detail: content is derived from provider data only, must be quoted as facts with no added predictions, null is a normal empty result with concrete causes, and non-English output is gated by the Insights feature. That is more than the annotations convey.

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?

Front-loaded with the core purpose and packs return fields, null behavior and language caveats into one dense paragraph with no filler. It reads as slightly run-on with many parenthetical clauses, but every clause carries information.

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

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

With no output schema, the description fully carries the return burden: it enumerates paragraphs, key_facts, what_it_means, summary_lang and summary_as_of, and explains when summary is null. For a read-only retrieval tool this is complete enough to call and interpret 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 baseline is 3, but the description adds real meaning: id accepts a code or number, the summary_lang/summary_as_of fields are named as outputs, and critically the lang values de/es/it/fr only yield a team or league summary — an important constraint not visible in the schema. That extra semantics pushes it above 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+resource: a ready-made summary (paragraphs) for a match, team, league or player, built from the provider's own data (table places, form, meetings, season). An agent can tell this is a pre-written narrative product rather than raw stats. It does not, however, explicitly differentiate itself from close siblings like get_match_briefing, get_team_briefing, get_facts or get_league_facts, which sound very similar.

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?

Gives useful situational context: key_facts appear before kick-off, what_it_means after the result, and summary is null when there is nothing (match in play, stale page, under-18 player). It also notes the non-English path requires the Insights feature and that only the sport is needed in the plan. But it never names an alternative tool or says when to prefer this over the briefing/facts siblings, leaving the routing decision to inference.

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

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

Annotations already declare a safe read operation, but the description adds substantial behavioral context beyond them: summary absence when not fresh, summary_lang fallback behavior, record_complete false meaning the record only covers from record_from, expected_return null meaning unknown and never to guess, matches_missed as a lower bound when incomplete, and honours source disagreements that must both be reported. It also notes feature requirements for facts and injuries. These are exactly the kinds of caveats an agent needs before calling.

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 dense run-on paragraph with nested semicolons and parentheticals, making it hard to scan. The information is relevant, but the structure is poor and not front-loaded into distinct sections, so it fails on readability and organization despite containing useful detail.

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

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

For a 10-parameter tool with no output schema, the description covers nearly all options, special-case returns for US sports, freshness caveats, and feature requirements. It is complete enough for an agent to call correctly, though the lack of clear organization and any concise return-shape summary keeps it from being fully polished.

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 largely mirrors the parameter meanings already in the schema (coach, squad, facts, season_stats, transfers, honours, injuries) and adds some useful context such as previous_coach/previous_club for coach and source disagreement handling for honours, but it does not add much per-parameter semantics beyond what the structured schema provides.

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 a team profile and enumerates the returned sections (country, founded, venue, leagues, rating, next matches, coach, squad_value). It also distinguishes itself from siblings by routing broader needs to get_matches and get_team_briefing. The verb is implicit in the tool name, and the dense enumeration makes the core purpose slightly harder to grasp at a glance, but it is unmistakably not a match or league tool.

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 names specific alternatives for specific needs: 'more: get_matches with team_id' for additional fixtures, 'fixture congestion: get_team_briefing', and 'more: get_transfers' for transfer history. It does not explicitly state when to use get_team over get_team_briefing as a whole or give broad exclusions, but the routing guidance is concrete and useful.

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 declare it as read-only and closed-world, and the description adds substantial behavioral context beyond that: injuries only apply to soccer, milestones appear only when statistics hold the whole season, and each item is also returned as a sentence in multiple languages. It does not contradict the annotations, though it does not discuss performance or error behavior.

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 very long, densely parenthetical sentence that is hard to scan. It contains relevant information but is poorly structured and front-loads little beyond the first clause, making it difficult for an agent to parse quickly.

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 complex briefing tool with no output schema, the description is quite complete: it enumerates the returned fields, conditional data availability, language handling, and the special tennis case. It could be clearer about what happens for unsupported sports, but overall it gives an agent enough to call 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 schema already defines all four parameters. The description adds marginal value by noting that team_id can come from find_teams or a match and that tennis uses a player id, but otherwise largely restates what the schema provides.

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

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

The description states a specific verb and resource: it produces a ready briefing for one team, with explicit sport exclusions (any sport but cricket; tennis uses a player id). It is clearly different from sibling tools like get_team or get_match_briefing, though it does not explicitly name those siblings to disambiguate further.

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

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

Usage is implied by the content list and the note that team_id comes from find_teams or a match, but there is no explicit guidance on when to choose this briefing over get_team or get_match_briefing. The sport restriction (not cricket) is useful but does not cover tool 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?

Annotations only declare readOnlyHint/openWorldHint/idempotentHint; the description goes well beyond them, disclosing that future-dated moves are excluded by default, what planned=true actually returns, and that profiles are re-read only every 30 days so the newest moves can be absent. It also states that fee_eur is often null and must never be reported as 0, which is a genuine data-interpretation rule.

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

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

Dense but front-loaded: the returned fields come first, then filtering, then caveats about exclusions and data freshness. A long single block, and the parenthetical field glosses make it heavy, but almost every clause carries information an agent needs.

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

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

With no output schema, the description fully compensates by enumerating return fields, enum-like values, and null-fee handling, plus the future-move exclusion and 30-day refresh lag. Nothing an agent needs to call or interpret this tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: direction only applies with team_id, league_id means moves in or out of that league's current teams, window is derived 'other by the date', and fee_eur nulls mean 'not known' rather than zero. That is meaningfully more than the schema text restates.

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 and resource ('Soccer transfers from player profiles') and then enumerates the exact fields returned (player, from/to team, date, season, window, type, fee_eur). No sibling tool covers transfers, so there is no ambiguity to resolve, and an agent can tell instantly what payload to expect.

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?

Gives concrete usage context: filter by league, team, season and window; sort by fee for biggest moves. It also clarifies when the returned set shifts (planned=true yields only moves after today). It stops short of naming an alternative tool or stating when not to use this one, but for a leaf data tool the routing 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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=false, so safety behavior is covered. The description adds that the tool is free and reports upcoming-match availability, but it does not describe the return shape or pagination.

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 core information is front-loaded: sports available, upcoming-match flag, and free. The routing list is long and dense, but it earns its place by directing agents to sport-specific tools.

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 zero-parameter discovery tool with no output schema, the description is mostly complete: it states the resource, the availability flag, cost, and where to go for detailed sport-specific data. A little more return-format clarity would make it fully complete.

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

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

The tool has zero parameters, which sets the baseline at 4. The description adds no parameter semantics because there are no inputs to explain.

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 and scope: sports available, each with an upcoming-matches flag. It is not written as an explicit verb phrase and does not differentiate from every sibling, but the routing notes for several sports make its role clear.

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 useful context by naming specialized alternatives for horse racing, MMA, golf, snooker/darts, and boxing. It does not explicitly state when not to use this tool or cover all sibling alternatives such as find_leagues, find_teams, or get_matches.

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