Server Quality Checklist

Tool Scores

• highlightly_soccer_leaguesC
  2.7/5.0
  Behavior3/5

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

  The description adds value beyond annotations by disclosing the return shape, including a caveat that it is unverified from vendor docs, and the authentication requirement. This transparency is positive. However, it introduces a misleading reference to a leagueId filter and lacks details on pagination behavior or rate limits. With annotations already covering readOnlyHint, openWorldHint, and idempotentHint, a score of 3 is appropriate.

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

  Conciseness4/5

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

  The description is compact and includes essential notes about the return shape, verification caveat, and auth. However, the line 'Example: Competitions covered' is redundant and adds no information, and the phrasing 'Football competitions covered' as an opening is awkward. It is still reasonably structured and not overly verbose.

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

  Completeness3/5

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

  For a simple listing tool, the description provides the return shape and auth, but the inaccurate leagueId mention and lack of clarity on pagination/filtering behavior leave gaps. The schema covers parameters, but the description could have resolved the leagueId discrepancy. Since there is no output schema, the return shape is helpful, though unverified. Adequate but with clear gaps.

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

  Parameters3/5

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

  Schema descriptions cover all three parameters (limit, leagueName, countryCode) at 100%, so the description doesn't need to repeat them. It adds no meaningful parameter information and even mentions a non-existent leagueId parameter, which is a negative. The baseline of 3 holds because the description doesn't enhance schema semantics but also doesn't materially detract, aside from the misleading reference.

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

  Purpose2/5

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

  The description is a noun phrase lacking an explicit verb, making the operation unclear. 'Football competitions covered, with the leagueId filters' doesn't clearly state that this tool lists football leagues, and it references a 'leagueId' filter that does not exist in the input schema. It gives the domain (football) but fails to specify the action or distinguish it from sibling tools like highlightly_soccer_matches.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention use cases for competition data, nor does it offer exclusions. The phrase 'with the leagueId filters' implies a use case but is unsupported by the schema. No alternative tools or conditions are referenced.

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

• entain_racing_future_marketsB
  3/5.0
  Behavior3/5

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

  Annotations already indicate readOnly, idempotent, and openWorld. The description adds useful context about auth ('Auth: none needed') and legacy status ('Legacy v1'), but does not elaborate on other behavioral traits such as data volume, pagination, or deprecated status risks.

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

  Conciseness5/5

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

  The description is extremely concise, containing three short lines that state the type, return format, and auth requirement. There is no fluff or redundant content, and the structure is clean with each line serving a distinct purpose.

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

  Completeness3/5

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

  The tool is simple with only two optional parameters and no output schema, and the description provides the return structure and auth. However, it lacks a high-level purpose statement and usage context, making it only marginally complete for an agent deciding when and how to invoke it.

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

  Parameters3/5

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

  The input schema has 100% description coverage for both parameters, with detailed descriptions for 'method' and 'exclude'. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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

  Purpose3/5

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

  The description 'Legacy v1 racing RPC selector (future-markets races feed)' provides a noun 'selector' rather than a clear action verb like 'list' or 'get'. It identifies the resource as future-markets races but does not clearly state what the tool does or how it relates to sibling tools such as entain_racing_racecard or entain_racing_next_races.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. The description does not mention any scenarios, prerequisites, or exclusions, leaving the agent with no help in choosing this over other racing feed tools.

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

• mlb_official_scorersB
  3/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to restate safety. It adds value by specifying the return structure ('roster:[{person, job}]') and explicitly stating that no authentication is needed, which goes beyond the annotations. However, it lacks details on filtering behavior, pagination, or edge cases.

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

  Conciseness5/5

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

  The description is extremely compact, using three short sentences or fragments to convey purpose, return format, and authentication requirement. Every piece of information serves a clear function, there is no repetition or filler, and the essential details are front-loaded.

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

  Completeness3/5

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

  For a simple read-only tool with two optional parameters, the description covers the return shape and authentication but omits how the parameters alter results and any behavioral notes about the response. With no output schema, the return line is valuable, yet the description remains minimal and could benefit from parameter-specific context.

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

  Parameters3/5

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

  The input schema provides full descriptions for both parameters (date as 'As-of date', sportId as 'Sport id.'), giving 100% schema description coverage. The tool description itself does not mention the parameters or how they affect the response, so it adds no extra meaning beyond what the schema already communicates. Baseline 3 is appropriate due to high schema coverage.

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

  Purpose3/5

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

  The description 'Official scorer assignments' identifies the resource but lacks an explicit verb like 'get' or 'list', making it more of a noun phrase than a clear action. The 'Returns: {roster:[{person, job}]}' line gives a hint of retrieval behavior, but the primary statement closely mirrors the tool name and does not differentiate from sibling tools such as mlb_umpires or mlb_datacasters.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of recommended use cases, prerequisites, or exclusions, and sibling tools with similar official role functionality are never referenced.

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

• footballdataorg_areasB
  3.1/5.0
  Behavior2/5

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

  The description adds useful caveats beyond the readOnly/idempotent annotations, notably that the return shape is unverified and should be inspected before relying on field names. However, it contains serious internal contradictions: the return shape is labeled 'VERIFIED (272 areas)' while a NOTE declares it has 'NOT been verified against a live response,' and auth is both 'works without a key' and 'needs your own key.' These contradictions actively undermine the agent's ability to trust the disclosed behavior.

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

  Conciseness2/5

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

  The description is short but not cleanly structured: 'VERIFIED' and 'has NOT been verified' appear in adjacent statements, and 'works without a key' directly contradicts 'needs your own key.' The 'Example: All areas' line adds little value. Redundant and contradictory content should have been reconciled before including it.

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

  Completeness3/5

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

  For a zero-parameter lookup tool, the description covers the essentials: what it is, the return shape, volume (272 areas), and the important caveat to inspect the actual payload. However, the contradictory verification and auth statements leave gaps in reliability, and there is no explicit pointer to the sibling competition tools that would consume these area IDs. It is adequate but not fully dependable.

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

  Parameters4/5

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

  With zero parameters and 100% schema coverage (vacuously), the description carries no parameter burden. The baseline of 4 for zero-parameter tools applies, and the description appropriately adds no unsupported parameter claims. The 'Example: All areas' hint reinforces that the tool returns the full set of areas.

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

  Purpose4/5

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

  The description clearly identifies the resource as countries/regions for filtering competitions, which adds meaning beyond the bare tool name. It includes a returns shape and example, reinforcing that this is a lookup tool. However, it lacks an explicit verb like 'List' or 'Get' and doesn't directly contrast with sibling tools such as footballdataorg_competitions.

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

  Usage Guidelines3/5

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

  The phrase 'used to filter competitions' provides clear contextual usage for when this lookup should be invoked. However, there are no explicit exclusions, alternative tool recommendations, or a described workflow (e.g., 'use returned area IDs with footballdataorg_competitions'). The contradictory auth statements ('works without a key' vs 'needs your own key in FOOTBALL_DATA_ORG_KEY') further muddy the practical guidance.

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

• polymarket_spreadB
  3.1/5.0
  Behavior3/5

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

  Annotations already establish read-only, idempotent, and open-world behavior. The description adds that no auth is needed and that the return is a spread object, but provides no further behavioral context such as error cases or data freshness. This offers modest value beyond annotations and does not contradict them.

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

  Conciseness3/5

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

  The description is short and the main purpose is front-loaded, but the sentence 'Also answers this: kalshi_orderbook' is cryptic and does not clearly earn its place. It reads as an out-of-place note that confuses rather than clarifies.

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

  Completeness3/5

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

  For a simple one-parameter read-only tool, the description covers the return shape and auth requirement. However, the ambiguous relationship to kalshi_orderbook and lack of detail about how the spread is computed or represented leave moderate gaps for an agent trying to select among similar prediction-market tools.

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

  Parameters3/5

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

  The schema already documents token_id as 'CLOB token id' with 100% coverage, so the description has a low bar to meet. The phrase 'one outcome token' reinforces the parameter's purpose but adds no new technical detail beyond the schema.

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

  Purpose4/5

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

  The first sentence clearly states the tool returns the bid-ask spread for one outcome token, which is a specific and understandable operation. However, the trailing 'Also answers this: kalshi_orderbook' introduces ambiguity about the exact scope and relationship to an existing sibling tool.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives like polymarket_price, polymarket_midpoint, or kalshi_orderbook. The cryptic 'Also answers this: kalshi_orderbook' is not an actionable usage guideline, and the only operational note is 'Auth: none needed.'

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

• betfair_event_detailsB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful context by specifying the exact return shape and that no auth is needed, but does not disclose potential pitfalls like event unavailability or rate limits. This is acceptable given the annotation coverage.

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

  Conciseness4/5

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

  The description is compact and well-structured: a one-line purpose statement, a return shape definition, and an auth note. Every sentence contributes useful information, though the return list is somewhat lengthy. It avoids unnecessary fluff.

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

  Completeness3/5

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

  Given the lack of an output schema, the description helpfully specifies the return fields and format. However, it does not mention how this tool relates to sibling tools or any prerequisites. For a simple read-only tool with good annotations and schema coverage, this is adequate but not fully complete.

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

  Parameters3/5

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

  The input schema has 100% description coverage for all five parameters, including defaults and meanings. The description does not add extra parameter semantics beyond what the schema already provides. The note about 'one or more events' is implied by the array type of eventIds, so no additional value is added.

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

  Purpose4/5

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

  The description clearly identifies the resource (event details) and lists the included fields (event name, competition, primary market, runners, start time). It is specific enough to distinguish from broadly named siblings like betfair_scores or betfair_market_prices, though it does not explicitly name an alternative.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus related siblings such as betfair_markets_by_event or betfair_scores. The 'In-play' qualifier implies a use case but there is no explicit when-to-use or when-not-to-use guidance.

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

• entitysport_competitionsB
  3.2/5.0
  Behavior4/5

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

  Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds that the response shape is unverified and that an ENTITYSPORT_TOKEN is required for auth. This provides useful context about reliability and access, exceeding what annotations alone convey.

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

  Conciseness4/5

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

  The description is organized into concise sections: purpose, return shape, verification note, example, and auth. It front-loads the core information and includes essential warnings without unnecessary elaboration.

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

  Completeness4/5

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

  Given the tool's simplicity (3 optional params, no output schema), the description provides a return shape, an example, a reliability warning, and auth details. It covers the key operational aspects, though the unverified shape leaves some uncertainty.

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

  Parameters3/5

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

  The input schema already describes all three parameters (paged, status, per_page) with clear descriptions. The example for status adds a sample value but does not fundamentally extend the schema's meaning. With 100% schema coverage, a baseline score of 3 is appropriate.

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

  Purpose3/5

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

  The description 'Competitions and tours.' with a returned item shape implies a list operation, but it lacks an explicit verb like 'list' or 'get'. It distinguishes from siblings primarily by the tool name rather than a clear statement of its action.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternative competitions tools. The example `{"status": "live"}` demonstrates a filter but provides no context for selection among siblings or exclusions.

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

• jolpicaf1_constructorsB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful context about the return structure (MRData) and states that no auth is needed, but it does not explain pagination via limit or any quirks about the required season parameter. It adds some value but not a rich behavioral layer.

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

  Conciseness4/5

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

  The description is compact and well-structured: a one-line scoping statement, a return format block, an example, and an auth note. Every section earns its place, though the all-time/season ambiguity adds slight unnecessary confusion. It is efficiently formatted with clear line breaks.

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

  Completeness3/5

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

  Given there is no output schema, the description's inclusion of the return shape is helpful. However, it lacks clarity on the all-time mode versus the required season parameter, and doesn't discuss the limit behavior or why openWorldHint might matter. For a simple list tool with strong annotations, it is adequate but leaves room for user confusion.

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

  Parameters2/5

  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 introduces ambiguity: it claims support for 'all-time' constructors while the schema marks 'season' as required, with no explanation of how to request all-time data. The example only shows a season-specific call, and the limit parameter's semantics are left entirely to the schema. This confuses rather than clarifies the parameters.

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

  Purpose4/5

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

  The description clearly names the resource (constructors/teams) and the scoping dimension (all-time vs. a single season), which distinguishes it from the sibling jolpicaf1_constructor_standings. The verb is implicit rather than explicit ('Constructors' as a noun), but the intended action of retrieving a list is unambiguous.

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

  Usage Guidelines3/5

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

  The description gives the two key use contexts (all-time or one season) and provides a concrete example with the season parameter. However, it does not explicitly state when to prefer this tool over siblings like jolpicaf1_races or jolpicaf1_constructor_standings, nor does it mention any exclusions or fallbacks.

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

• mlb_datacastersB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description only adds 'Auth: none needed' and the return shape. This is useful but minimal; it does not elaborate on data scoping, default behavior, or edge cases. 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.

  Conciseness4/5

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

  The description is only three lines and includes the definition, return format, and authentication requirement without redundancy. It is concise, though the first line uses jargon that may require disambiguation.

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

  Completeness3/5

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

  For a simple read-only tool with optional parameters and no output schema, the return format is stated inline and auth is covered. However, it does not explain the effect of the date/sportId parameters in context or provide typical usage scenarios, leaving some gaps for an agent.

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

  Parameters3/5

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

  Schema coverage is 100%, with both 'date' and 'sportId' having descriptions. The tool description adds no further meaning about these parameters, so it meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly identifies the resource as 'datacaster assignments' and provides the return structure ({roster:[{person, job}]}), distinguishing it from other MLB personnel tools like mlb_official_scorers. However, it lacks an explicit verb such as 'get' or 'list', relying on the word 'Returns' to imply retrieval.

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

  Usage Guidelines2/5

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

  No guidance is given about when to use this tool versus alternatives. The description does not mention use cases, prerequisites, or when not to use it, leaving the agent without decision-making context for selecting 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.

• openf1_team_radioB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description adds 'Auth: none needed' and the exact return format (list of fields). This is useful but the unexplained 'Also answers this: afl_live_audio' introduces a potentially misleading behavioral claim. No contradiction with annotations, but the added context is partially confusing rather than purely clarifying.

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

  Conciseness4/5

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

  The description is brief and front-loaded: purpose first, then return format, then auth. The extra line 'Also answers this: afl_live_audio' is cryptic and could be considered noise, but the overall structure is efficient and easy to scan.

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

  Completeness3/5

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

  The description provides the output fields and auth requirement, which is important given there is no output schema. However, it doesn't explain behavior when no parameters are provided, how 'latest' works in practice, or clarify the odd afl_live_audio reference. It is complete enough for basic use but leaves conceptual gaps.

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

  Parameters3/5

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

  Schema description coverage is 100% with each parameter having a brief description (e.g., 'Meeting key, or latest'). The tool description does not add further parameter usage details, but the schema already provides the necessary semantics, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool provides 'recording URLs of driver/pit-wall radio exchanges during a session', which is a specific resource with a clear scope. It distinguishes itself from other OpenF1 data tools by focusing on team-radio clips. The final line 'Also answers this: afl_live_audio' is confusing and slightly muddies the purpose, but the core statement remains clear.

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

  Usage Guidelines2/5

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

  There is no explicit guidance on when to use this tool versus alternatives. The only reference to another tool is 'Also answers this: afl_live_audio', which is ambiguous and does not clarify selection criteria. It lacks exclusions, prerequisites, or contextual cues for when this tool is the appropriate choice among the many OpenF1 and audio-related tools.

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

• sleeper_draftB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the bar is lower. The description adds value by stating 'Auth: none needed' and listing the exact return structure, but it does not disclose any other behavioral traits (e.g., behavior on missing draft_id, pagination, or rate limits). This is adequate for a simple read-only tool.

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

  Conciseness4/5

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

  The description is compact: a purpose line, a returns list, a short example, and an auth note. There is no fluff, and the most important information is front-loaded. The example label ('Example: A draft's settings') is slightly ambiguous because it shows the request parameter rather than the returned settings, but it is still reasonably clear.

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

  Completeness4/5

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

  Given the tool's low complexity (one parameter, no output schema, read-only annotations), the description covers the essential points: what the tool does, what it returns, an example, and authentication requirements. It could be improved by noting that the draft_id should be obtained from a prior call, but the schema already hints at this. Overall, it is sufficiently complete for an agent to invoke correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the schema already explains that draft_id comes from sleeper_league_drafts and is part of the URL path. The description adds little beyond an example value, so it does not meaningfully compensate or expand beyond the schema. Baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly identifies the resource as 'One draft's configuration' and enumerates the fields included, making it distinct from sibling tools like sleeper_league_drafts (which lists drafts) and sleeper_draft_picks (which fetches picks). However, it lacks an explicit verb such as 'Get' or 'Retrieve', relying on the tool name and return section to convey the operation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions. The only contextual hint is in the schema ('from sleeper_league_drafts'), which hints at a prerequisite but is not part of the description itself. The example shows a request but no comparative usage advice.

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

• afl_broadcast_match_eventsB
  3.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to restate safety. It adds useful context by specifying the return format ({pageInfo, content:[...]}) and stating 'Auth: none needed.' The 'Also answers' line is confusing, but it does not contradict the annotations or claim side effects.

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

  Conciseness3/5

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

  The description is mostly concise with a clear purpose, return format, and auth note. However, the final line 'Also answers this: espn_core_call, pl_broadcasting_events, pl_broadcast_match_events' is unnecessary and confusing, undermining the structure and wasting space. It detracts from an otherwise efficient description.

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

  Completeness3/5

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

  For a simple read-only tool with a full schema and no output schema, the description provides the essential return structure and auth requirement. However, it does not situate the tool among its many siblings or clarify the cryptic 'Also answers' note. It is adequate but leaves gaps around positioning and edge-case behavior (e.g., pagination semantics beyond pageSize).

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

  Parameters3/5

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

  The input schema already documents all three parameters (round, pageSize, compseason) with descriptions, so schema coverage is 100%. The description adds no extra parameter semantics beyond reaffirming that events are scoped to compseason and round, which mirrors the required fields. This is a baseline-3 scenario where the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the tool broadcasts events scoped to a (compseason, round), which matches the tool's name and distinguishes it from single-event tools like afl_broadcast_event_get. However, it could be more explicit about the type of events (e.g., 'match events') and does not fully differentiate from other broadcast-related siblings like afl_broadcast_events.

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

  Usage Guidelines2/5

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

  The description offers no clear guidance on when to use this tool versus alternatives. The line 'Also answers this: espn_core_call, pl_broadcasting_events, pl_broadcast_match_events' is cryptic and does not explain usage context, preconditions, or exclusions. It fails to help an agent choose this tool over similar ones.

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

• betfair_market_pricesB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnly, openWorld, and idempotent. The description adds that no auth is needed and shows the full return structure, but doesn't mention rate limits or error behavior. With annotations, this is adequate but not exceptional.

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

  Conciseness4/5

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

  Includes a compact summary, return structure, example, and auth note without excess. The return structure is verbose but useful given no output schema. Well-structured and front-loaded.

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

  Completeness4/5

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

  Provides return shape, example, and auth requirement, covering the essentials for a read-only data fetch. Does not explain pagination or caveats, but for a simple price feed with full schema descriptions, this is adequate.

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

  Parameters2/5

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

  Schema has 100% coverage, but the description's example shows marketIds as a comma-separated string while the schema declares it as an array—a contradictory signal. This could mislead the agent into passing the wrong type.

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

  Purpose4/5

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

  Clearly states it returns exchange back/lay prices and market state for one or more markets, positioning it as the core odds feed. Distinguishes from siblings like betfair_scores or betfair_event_details through its focus on prices/state.

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

  Usage Guidelines3/5

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

  Implied usage as the core odds feed suggests primary use for odds data, but no explicit when/when-not or alternative tool names. The example illustrates invocation but doesn't provide decision guidance.

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

• mlb_schedule_tiedB
  3.3/5.0
  Behavior3/5

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

  The description discloses the return structure ({totalGames, dates:[{games:[...]}]}) and states that no Auth is needed, adding value beyond the readOnlyHint/idempotentHint annotations. However, it leaves semantic ambiguity about what qualifies as a 'tied' game (e.g., tiebreaker games vs. games ending in a tie). 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.

  Conciseness5/5

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

  The description is extremely concise and front-loaded: it states the tool's purpose, expected return shape, and authentication requirement in just three lines. Every phrase contributes useful information without redundancy.

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

  Completeness3/5

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

  For a tool with three parameters and no output schema, the description gives a minimal return structure but omits clarification on the data scope (tie-breaker vs. tied games) and how parameters like hydrate and gameTypes affect the output. It covers the basics but leaves meaningful gaps for an agent to correctly interpret results.

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

  Parameters3/5

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

  Since the input schema provides 100% coverage for all three parameters, the description need not add much parameter detail. It offers no additional meaning beyond the schema, only implicitly referencing the season parameter. This meets the baseline but does not enhance understanding.

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

  Purpose4/5

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

  The description identifies the resource as 'tie-breaker / tied games for a season,' which clearly indicates the subject matter. However, it lacks an explicit verb like 'retrieve' or 'list,' and does not differentiate from sibling tools such as mlb_schedule or mlb_schedule_postseason.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives. It only says 'for a season,' implying a season-based query scope, but fails to mention when not to use it or how it differs from other MLB schedule tools in the sibling list.

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

• polymarket_priceB
  3.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering safety and idempotency. The description adds that no auth is needed and specifies the return shape as {price}, which is useful behavioral context beyond the annotations.

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

  Conciseness3/5

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

  The description is short and front-loaded with the core purpose, but the final sentence 'Also answers this: kalshi_orderbook' is unclear and does not contribute meaningful structure, slightly detracting from overall conciseness.

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

  Completeness3/5

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

  For a simple tool with two parameters and no output schema, the description covers purpose, return format, and auth. However, it lacks clear guidance on how this tool relates to similar siblings, leaving some contextual gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both token_id and side clearly documented. The description's phrase 'one outcome token on one side of the book' adds minimal additional meaning, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool returns the best price for one outcome token on one side of the book, distinguishing it from other Polymarket price tools. However, the line 'Also answers this: kalshi_orderbook' introduces ambiguity about the tool's exact scope, so it isn't a perfect 5.

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

  Usage Guidelines2/5

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

  No explicit when-to-use or alternative-tool guidance is provided. The reference to kalshi_orderbook is vague and does not clarify when to prefer this tool over sibling tools like polymarket_book or polymarket_midpoint.

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

• afl_seasons_listB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds the return format and the fact that no auth is needed, which is useful but does not elaborate on pagination behavior or the contents of 'meta'. It does not contradict 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.

  Conciseness5/5

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

  The description is extremely concise, with the core purpose in the first line and return/auth details in two short lines. Every sentence provides useful information, with no fluff or repetition.

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

  Completeness4/5

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

  For a simple list tool with no output schema, the description adequately covers the return shape and auth requirements. However, it leaves 'meta' undefined and does not mention any ordering or default behaviors, which are minor gaps given the low complexity and rich annotations.

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

  Parameters3/5

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

  Schema description coverage is 100%, with 'page' and 'pageSize' both described clearly. The description adds no additional parameter information, so the baseline of 3 applies.

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

  Purpose4/5

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

  The description uses the specific verb 'List' with resource 'calendar-year season records', and defines the return shape as {meta, seasons:[{id, year}]}. This clearly states what the tool does, though it does not explicitly contrast with sibling tools like afl_compseasons_list or afl_season_get.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives (e.g., afl_compseasons_list for competition-specific seasons or afl_season_get for a single season). The phrase 'calendar-year season records' provides an implicit hint, but no explicit usage context or exclusions are given.

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

• betfair_cashoutB
  3.4/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds useful context with 'Auth: none needed' and the exact return shape, which goes beyond the annotations. No contradictions.

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

  Conciseness5/5

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

  The description is extremely concise with four short lines covering purpose, return format, and auth. Every sentence earns its place with zero fluff or repetition.

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

  Completeness4/5

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

  For a simple read-only endpoint, the description covers the essential aspects: what it does, what it returns, and authentication. The lack of an output schema is compensated by the inline return specification. The only minor gap is that input format for marketIds could be clearer given the array/string ambiguity, but the schema handles the parameter definitions.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema fully documents the parameters. The description itself does not add param-level detail. Note the schema's marketIds type is array but its description says 'comma-separated', a potential confusion, but that is a schema issue, not a description gap.

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

  Purpose4/5

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

  The description clearly states that the tool provides cash-out availability for one or more markets, and the inline return format specifies the output fields. It effectively distinguishes this from sibling Betfair tools which focus on other data like scores or market prices, though it lacks an explicit verb like 'get' or 'list'.

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

  Usage Guidelines2/5

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

  The description gives no explicit guidance on when to use this tool versus alternatives. The phrase 'for one or more markets' is the only scope hint, but there is no mention of selecting this over other Betfair market data tools or any exclusion criteria.

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

• datagolf_matchupsB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds a return structure and the requirement for a DATAGOLF_KEY, but does not disclose other behavioral traits such as data freshness, pagination, or rate limits.

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

  Conciseness5/5

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

  The description is extremely concise, with a one-sentence summary followed by a compact return shape and auth note. Every sentence provides value without redundancy.

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

  Completeness4/5

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

  The description provides a partial output schema in the Returns block and notes the authentication requirement, which is helpful given no output schema exists. It covers the essential usage context, although it could be more explicit about how odds keys vary across sportsbooks or the live/historical nature of the data.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all parameters are already well-documented with enums and defaults. The description adds no extra meaning beyond the schema, making this a baseline score.

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

  Purpose4/5

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

  The description clearly states that the tool provides tournament, round, and 3-ball matchup odds across sportsbooks plus Data Golf's model line. This is specific about the resource and scope, but it does not explicitly differentiate from the similarly named sibling datagolf_matchups_all_pairings.

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

  Usage Guidelines2/5

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

  The description does not provide explicit when-to-use guidance or mention alternatives. While the purpose implies use for matchup odds in these markets, there is no contrast with sibling tools like datagolf_matchups_all_pairings or historical matchup tools, leaving the agent to infer the appropriate context.

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

• jolpicaf1_circuitsB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds the exact JSON return shape and states no authentication is required, which is useful. However, it does not disclose pagination behavior, error handling, or rate limits, leaving some behavioral uncertainty beyond what annotations provide.

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

  Conciseness5/5

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

  The description is compact—three short lines plus an example and an auth note. Every element contributes: the resource definition, return structure, a concrete example, and auth requirement. There is no redundant or filler content.

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

  Completeness4/5

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

  For a read-only, idempotent list endpoint with full schema coverage and an explicit return structure, the description is mostly sufficient. The main gap is the lack of usage context relative to sibling tools, but the example and output format provide adequate operational detail for a tool of this simplicity.

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

  Parameters3/5

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

  The input schema already covers all three parameters (season, limit, format) with descriptions, defaults, and constraints, achieving 100% schema coverage. The description's example illustrates passing season and format but adds no semantic detail beyond what the schema provides, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description identifies the resource as 'Circuits' and states it includes location and coordinates, plus a full return structure. The example with season 2024 demonstrates the intended use of retrieving circuits for a season. However, the opening is a noun phrase without an explicit verb like 'lists' or 'gets', so it is clear but not fully explicit.

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

  Usage Guidelines2/5

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

  The description provides an example call but no guidance on when to use this tool over sibling F1 tools (e.g., jolpicaf1_races, jolpicaf1_drivers). It does not mention any exclusions or alternatives, so an agent receives no decision-making information about when this tool is the appropriate choice.

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

• mlb_conferencesB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that no auth is needed and gives the exact return shape, which is useful context. It does not disclose additional behavior like default parameter handling or pagination, but for a simple read-only catalogue, the added information is adequate.

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

  Conciseness5/5

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

  The description is very concise: a short title, a return shape, and an auth note. Every sentence provides useful information with no redundancy. It is well-structured and front-loaded with the core purpose.

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

  Completeness4/5

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

  For a simple catalogue tool with no output schema, the description provides essential information: the return fields and auth requirement. It does not explicitly state default behavior when no filters are provided, but this is inferable from the schema's default null values. Overall, it is sufficiently complete for a read-only list tool.

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

  Parameters3/5

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

  The input schema provides descriptions for both parameters (season year, filter to one conference), achieving 100% schema coverage. The description adds no further parameter semantics, so it does not go beyond what the schema already states. Baseline 3 is appropriate.

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

  Purpose4/5

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

  The description states it is a 'Conference catalogue' and details the return structure (id, name, abbreviation, league, hasWildcard), making it clear this tool lists conferences. It is distinct from sibling tools like mlb_divisions and mlb_leagues. The phrasing is a noun rather than an explicit action, but the 'Returns' line clarifies it is a retrieval operation.

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

  Usage Guidelines2/5

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

  The description offers no explicit guidance on when to use this tool versus alternatives. It notes conferences are 'used by some leagues / amateur levels,' hinting at context, but does not state exclusions or recommend other tools. There is no mention of when to apply the season or conferenceId filters.

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

• mlb_draft_prospectsB
  3.4/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, which cover the safety profile. The description adds useful return shape information and confirms no auth is needed, but does not disclose any further behavioral traits such as pagination, ordering, or potential errors. This adds some value beyond annotations but is not extensive.

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

  Conciseness5/5

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

  The description is exceptionally concise: one sentence of purpose, one line for return shape, and a short auth note. Every element earns its place, with no redundancy or wordiness.

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

  Completeness4/5

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

  Given the simplicity of the tool (3 parameters, no output schema), the description includes the return shape, which is essential. Combined with good schema descriptions and annotations, the agent has enough context to invoke it correctly. It lacks details like default limit behavior or interpretation of 'round', but these are minor given the schema descriptions.

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

  Parameters3/5

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

  Schema description coverage is 100%, with each parameter adequately described ('Draft year. Required — part of the URL path.', 'Max prospects.', 'Filter to a round.'). The description itself does not add any extra meaning about parameters beyond what the schema already provides, so it meets the baseline of 3.

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

  Purpose4/5

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

  The description clearly states the tool returns draft prospects for a year, specifically the pre-draft prospect board. It identifies the resource (prospects) and the scope (by year). However, it does not differentiate from the sibling tool 'mlb_draft' which is also MLB draft related, so it lacks explicit sibling differentiation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'mlb_draft' or other MLB prospect tools. It only mentions that no authentication is needed, which is not a usage guideline. There is no mention of typical use cases or exclusions.

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

• mlb_leadersB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the base safety profile is covered. The description adds value by stating that no authentication is needed and providing the exact return shape. However, it does not disclose additional behavioral traits such as default season/limit behavior or potential error conditions.

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

  Conciseness5/5

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

  The description is extremely concise, with only three sentences: purpose, return format, and auth. It is front-loaded with the main verb and resource, and every sentence contributes meaningful information without repetition.

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

  Completeness4/5

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

  Given the lack of an output schema, the description provides a helpful return-shape example. It covers authentication and clarifies the categories. However, it omits default behavior for optional parameters (e.g., season, limit), though those are documented in the schema. For a read-only tool with strong annotations, this is largely complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all six parameters are already well-documented. The description adds some context by listing example leaderCategories and showing how statGroup appears in the return shape, but it does not materially enhance parameter understanding beyond the schema.

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

  Purpose4/5

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

  The description clearly states the tool returns league leaders for specified categories, with a specific verb ('League leaders') and examples. However, it does not explicitly differentiate from sibling tools like mlb_team_leaders or other league-leader tools, so it falls short of full sibling distinction.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. The description describes what it does but does not mention any exclusions, alternatives, or scenarios where another tool would be more appropriate.

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

• mlb_team_coachesB
  3.4/5.0
  Behavior4/5

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

  Adds useful behavioral context beyond the annotations: no authentication needed, and the return structure is explicitly outlined. The annotations already indicate read-only/idempotent behavior, and the description complements this without contradiction.

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

  Conciseness4/5

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

  The description is compact, front-loaded with the core purpose, and includes return format and auth. The final line about espn_core_call is somewhat vague but doesn't add significant bloat.

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

  Completeness3/5

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

  The description covers the what, the return shape, and auth, but lacks any usage guidance or differentiation from sibling tools. Given no output schema, the return format line is helpful, yet overall completeness is only partial.

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

  Parameters3/5

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

  Input schema description coverage is 100%, so the schema fully documents the three parameters. The description doesn't add extra semantics beyond the schema, which is acceptable per baseline.

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

  Purpose4/5

  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's coaching staff with specific roles (manager, hitting/pitching/bench coaches). It lacks an explicit verb like 'get' or 'retrieve,' but the content and return schema make the purpose unambiguous.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus other MLB team tools (e.g., mlb_team_roster, mlb_team_personnel). The note 'Also answers this: espn_core_call' is cryptic and does not clarify selection criteria or exclusions.

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

• mlb_umpiresB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the bar is lower. The description adds 'Auth: none needed' and the return shape, which are useful. However, it doesn't disclose other behavioral aspects like whether the date parameter is optional or how 'current' is determined, leaving some ambiguity.

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

  Conciseness5/5

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

  The description is extremely concise, using only three short lines to convey the purpose, return format, and authentication requirement. Every sentence contributes value with no redundancy or filler, and the structure is immediately scannable.

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

  Completeness4/5

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

  For a simple listing tool, the description covers the core elements: what it returns (roster with person, jobType, job) and that no auth is needed. It does not explain the exact meaning of 'jobType' or 'job', but the provided return shape suffices for basic use. It could benefit from mentioning how the optional 'date' and 'sportId' parameters affect the result, but the overall completeness is adequate.

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

  Parameters3/5

  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's use of 'Current' adds slight context to the date parameter's default behavior, but it does not go beyond what the schema already provides for either parameter. No extra meaning is added.

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

  Purpose4/5

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

  The description clearly identifies the resource as a 'Current umpire crew list' and provides a return shape, making the tool's purpose understandable. It lacks an explicit verb but the 'Returns:' line clarifies it is a data retrieval operation. It distinguishes itself from sibling tools like mlb_official_scorers by focusing specifically on umpires.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives or when not to use it. The phrase 'Current umpire crew list' implies it is for the current umpire crew, but it does not explain scenarios like historical queries or how to choose between this and related MLB tools. No exclusions or alternative references are provided.

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

• oddsapiio_bookmakersB
  3.4/5.0
  Behavior2/5

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

  Annotations already declare readOnly/idempotent/openWorld hints, but description adds a caveat about unverified shape, which is helpful. However, the auth contradiction and lack of clarity about whether a key is required undermines trust; the user can't tell if the tool will work without credentials.

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

  Conciseness3/5

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

  The description is verbose with redundancies ('274 bookmakers' twice, 'VERIFIED live' repeated). The note about unverified shape is long and could be more concise, but it is structured with sections.

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

  Completeness4/5

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

  For a zero-param list tool, it covers return shape, counts, and a caveat about reliability. However, the auth contradiction is a gap that prevents full clarity, and there's no mention of pagination or error handling.

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

  Parameters4/5

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

  There are zero parameters, so schema coverage is 100% and no param semantics needed. The description adds an example of the return shape which is useful given no output schema, though not directly about parameters.

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

  Purpose5/5

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

  The description clearly states the tool returns the 274 indexed bookmakers with active status, using a specific resource and action. It's distinct from sibling tools like oddsapiio_sports or oddsapiio_odds which focus on other entities.

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

  Usage Guidelines2/5

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

  No explicit when-to-use guidance or alternative differentiation. It mentions names are used as filters in odds calls, which subtly implies usage, but the contradictory auth statements ('works without a key' vs 'needs your own key') confuse selection and invalidation.

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

• pl_player_season_statsB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, establishing the safety and openness of the operation. The description adds 'Auth: none needed' and a return shape, which are useful context, but it does not elaborate on what 'Opta metrics' includes or potential edge cases. This is modest additional 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.

  Conciseness5/5

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

  The description is extremely concise: a one-line purpose, a return type summary, and an auth note. Every sentence serves a distinct purpose, and the most important information (what the tool returns) is front-loaded. No fluff or repetition.

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

  Completeness4/5

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

  For a simple read-only tool with all parameters documented in the schema and safety declared through annotations, the description is nearly complete: it states the purpose, the return shape, and auth requirements. It falls slightly short by not providing any usage guidance or caveats about data availability, but given the tool's simplicity, this is a minor gap.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with each parameter clearly explained (e.g., 'Competition id (8)', 'Player id', 'Season id'). The description adds no additional parameter-specific semantics, so it does not improve on the baseline established by the schema.

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

  Purpose4/5

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

  The description clearly states the resource: 'A player's stats for one season.' This identifies the scope (single season) and the subject (player), which distinguishes it from broader player tools. However, it lacks an explicit verb like 'get' or 'retrieve', and does not reference sibling tools, so it is clear but not fully differentiated.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or comparison to related tools like pl_player_comp_stats or pl_player_info. The agent is left to infer usefulness from the name and brief description.

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

• sportsbet_league_ladderB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral context with 'Auth: none needed' and the return shape, but does not disclose any pagination, ordering, or edge-case behavior. This is a moderate addition 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.

  Conciseness5/5

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

  The description is compact and well-structured: a one-line purpose, a return snippet, and an auth note. Every sentence provides distinct value, and there is zero filler.

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

  Completeness4/5

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

  The tool is simple (one required parameter, read-only, no output schema). The description covers purpose, return schema, and auth. Given the low complexity and complete schema, this is sufficient. A small deduction for not mentioning potential errors or result size, but overall adequate.

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

  Parameters3/5

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

  Schema description coverage is 100%: the single competitionId parameter is documented in the schema ('Sport competition id. Required — part of the URL path.'). The description adds no additional meaning about the parameter, so the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool provides a league ladder/standings for a sport competition, and explicitly lists the return fields. This is specific enough to distinguish from many non-ladder tools, but it doesn't differentiate from other ladder tools in the sibling list (e.g., nbl_ladder, squiggle_ladder) in terms of source or scope.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool vs alternatives. It doesn't mention any prerequisites, exclusions, or scenarios where another tool would be preferred. The only context ('for a sport competition') is implied by the resource, not a genuine usage guideline.

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

• sportsbet_racing_popular_srmsB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, reducing the bar. The description adds 'Auth: none needed' and the return format, which are useful behavioral context beyond annotations. But it does not disclose data limitations, pagination, or the meaning of the 'Also answers' alias, 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.

  Conciseness4/5

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

  The description is brief and front-loaded, with only three lines covering purpose, return format, and auth. The 'Also answers this' line is vague and could confuse, preventing a perfect score, but overall the structure is clean and efficient.

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

  Completeness3/5

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

  For a read-only tool with 6 parameters and no output schema, it provides essential return format and auth info. However, it lacks explanation of how hierarchyLevel/ids map to races vs. meetings, what 'popular' entails, and the cryptic alias note. It is minimally viable but leaves gaps for a complex betting domain.

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

  Parameters3/5

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

  Schema coverage is 100% with well-described parameters, so the description is not required to compensate. It adds no extra parameter semantics beyond what the schema provides. The description's focus on 'popular' aligns with the 'popularsrms' parameter but does not explain relationships or usage nuances.

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

  Purpose4/5

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

  The description clearly states it returns 'Popular Same Race Multi (SRM) combinations for races / meetings' and provides a return format, establishing a specific resource and scope. It distinguishes from siblings by emphasizing 'popular' and mentioning entain_graphql_call and pointsbet_racing_srm, though this reference is cryptic. The purpose is evident and actionable.

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

  Usage Guidelines3/5

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

  There is some implied guidance: use for popular SRMs across races/meetings, and the note about 'also answers' indicates potential overlap with other tools. However, it lacks explicit when-to-use vs. alternatives, exclusions, or conditions like event vs. meeting selection. The alias statement is too ambiguous to serve as clear guidance.

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

• sportsbet_results_competitionsB
  3.4/5.0
  Behavior3/5

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

  Annotations already convey read-only, idempotent, and open-world hints. The description adds the return structure and explicit 'Auth: none needed,' but does not disclose additional behavioral traits like pagination, empty response behavior, or potential data volume. It provides some value beyond annotations but not extensive context.

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

  Conciseness5/5

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

  The description is exceptionally concise and well-structured, with a clear purpose line, a compact return format, and an auth note. Every sentence earns its place, with no redundant or misleading content.

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

  Completeness4/5

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

  For a simple read-only tool with two parameters and no output schema, the description covers the purpose, return shape, and auth. It lacks usage guidance and does not explain the concept of 'sport class' or direct the agent to related tools, but combined with annotations and schema it is reasonably complete.

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

  Parameters3/5

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

  Schema coverage is 100%, so both parameters (classId and date) are fully documented in the schema. The description does not add extra semantics beyond what the schema already explains; the return structure hints at their purpose but does not clarify formats or constraints further.

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

  Purpose4/5

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

  The description clearly states the resource (competitions), the filtering criteria (sport class, date), and the output (results). It is specific enough to distinguish from event-level results tools, though it lacks an explicit verb like 'list' or 'get' and does not directly contrast with sibling tools.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or suitable scenarios, leaving the agent to infer usage from the name and description alone.

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

• sportsbet_trending_sgmB
  3.4/5.0
  Behavior3/5

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

  The description adds useful context by stating 'Auth: none needed' and providing a return structure, which builds on the read-only and idempotent annotations. However, it doesn't disclose potential limitations like data freshness, pagination, or the meaning of 'trending,' so it provides moderate transparency 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.

  Conciseness5/5

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

  The description is extremely concise, with three short sentences covering purpose, return shape, and authentication requirements. It is front-loaded with the main purpose and contains no redundant information.

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

  Completeness4/5

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

  For a simple read-only tool with one parameter, the description is largely complete: it explains the resource, scope, return structure, and auth. It could optionally mention that 'trending' data may change (openWorldHint), but the annotation already covers that, so the description suffices.

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

  Parameters3/5

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

  The input schema already describes 'id' as 'Sport event id,' and the description does not add any further semantic detail. With 100% schema coverage, the baseline of 3 applies, as no additional parameter context or examples are provided.

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

  Purpose4/5

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

  The description clearly states the tool provides 'Trending Same Game Multi (SGM) combinations for one sport event,' identifying the resource and scope. However, it lacks an explicit verb like 'get' or 'fetch' and doesn't differentiate from sibling tools such as sportsbet_event_markets, so it stops short of the highest rating.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It only states what it returns, with no mention of suitable use cases, prerequisites, or exclusions, leaving the agent to infer appropriate usage.

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

• tab_racing_race_formB
  3.4/5.0
  Behavior3/5

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

  The description adds auth context (works without a key, but more data with credentials), which is not covered in annotations. However, it does not discuss other behaviors like rate limits, data freshness, or potential side effects beyond the read-only annotation.

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

  Conciseness5/5

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

  The description is concise and well-structured, covering the tool's purpose, return structure, and authentication in a compact manner with no redundancy or extraneous details.

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

  Completeness4/5

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

  Given the simplicity of the tool and the detailed parameter schema, the description is mostly complete. It includes the return structure and auth details, but lacks any mention of data source, update frequency, or potential limitations, which would make it more robust.

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

  Parameters3/5

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

  The input schema provides clear descriptions for all parameters, and the tool description does not add additional meaning beyond what is already documented. The parameter explanations are sufficient, but the description itself provides no extra insight.

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

  Purpose5/5

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

  The description clearly states it provides a detailed form guide for one race, specifying past performances, ratings, and comments per runner. It also includes the return structure, making the purpose unambiguous.

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

  Usage Guidelines1/5

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

  No guidance is given on when to use this tool versus alternatives such as tab_racing_race or tab_racing_runner_form. The description lacks any context about appropriate use cases or differentiation from sibling tools.

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

• betr_sports_categoryA
  3.5/5.0
  Behavior3/5

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

  Annotations already cover read-only, open-world, and idempotent behavior. The description adds 'Auth: none needed' and the return structure, which is useful context. However, it doesn't disclose other behavioral details like pagination or rate limits, so it only modestly exceeds the annotation baseline.

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

  Conciseness5/5

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

  The description is concise and well-structured: a one-line purpose, a return format, and an auth note. Every sentence earns its place with no redundancy.

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

  Completeness5/5

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

  For a simple single-parameter read-only tool with good annotations, the description includes the return shape and auth requirements, making it complete. The textual return structure compensates for the absence of an output schema.

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

  Parameters3/5

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

  The schema already has 100% coverage for the single parameter CategoryId, with a clear example. The description does not add meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool returns events and markets for a single sport category/competition, which is a specific verb+resource+scope. It distinguishes from broader tools like betr_master_category by focusing on a single category, though it doesn't explicitly name alternatives.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description implies it is used when you have a CategoryId, but there is no mention of when not to use it or what competing tools exist for similar purposes.

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

• cfbd_rankingsA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is known. The description adds valuable behavioral context by explicitly noting that the return shape is from vendor docs and unverified, warns the agent to inspect the actual payload, and discloses that the provider key is absent. This goes beyond the annotations and helps set expectations.

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

  Conciseness4/5

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

  The description is moderately sized and front-loaded with the core purpose, then return shape, caveat, example, and auth. It is structured with clear sections, but the caveat and example are somewhat verbose. Every sentence provides useful information, though the example could be considered redundant given the shape. Overall, it is efficient and well-organized.

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

  Completeness4/5

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

  Since there is no output schema, the description carries the burden of explaining the return structure, which it does thoroughly with a nested shape example and nesting note. It also covers authentication and includes usage caveats. It lacks potential details like pagination or error behavior, but for a 3-parameter read-only tool, it is sufficiently complete.

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

  Parameters3/5

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

  The input schema provides 100% description coverage for all three parameters (year, week, seasonType), so the schema already handles parameter semantics. The description adds a concrete example ('2024 week 10 polls') but this does not significantly deepen understanding beyond what the schema offers. Baseline 3 is appropriate when schema covers all parameters.

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

  Purpose4/5

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

  The description clearly identifies the tool as providing weekly poll rankings (AP, Coaches, Playoff Committee), which is a specific resource distinct from other CFBD tools like cfbd_ratings_elo or cfbd_games. It lacks an explicit verb like 'Retrieve' or 'List', but the title and description together make the purpose unambiguous.

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

  Usage Guidelines2/5

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

  The description does not provide guidance on when to use this tool versus alternatives among the CFBD siblings. It implies usage for poll rankings but does not explicitly state exclusions or mention alternative tools for other rating types (e.g., cfbd_ratings_elo). The auth note is a prerequisite, not a tool-selection guideline.

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

• chesscom_clubA
  3.5/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds 'Auth: none needed' and the expected return structure, which provides some behavioral context. It doesn't mention error cases, rate limits, or pagination, but for a simple read operation with annotations, this is adequate.

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

  Conciseness4/5

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

  The description is well-structured with a brief summary, a return fields list, an example, and an auth statement. It is appropriately sized and front-loads the core information, with no redundant sentences. The example adds clarity without excessive length.

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

  Completeness4/5

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

  Given the tool's simplicity (one parameter, no output schema), the description covers the essential context: what the club data is, what fields are returned, how to specify the club, and that no auth is needed. It lacks details on error handling or variations in response, but for this scope it is fairly complete.

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

  Parameters3/5

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

  The input schema already provides comprehensive documentation for club_id, including the format and example (100% schema description coverage). The description's example and 'part of the URL path' note in the schema overlap, adding minimal new semantic value. The baseline of 3 applies since the schema carries the load.

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

  Purpose4/5

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

  The description clearly identifies the resource (Chess.com club) and lists the data fields returned (description, membership count, admins, average rating), which implies a retrieval operation. It doesn't use a strong verb like 'get' or 'fetch', but the 'Returns:' format makes the purpose clear. It distinguishes itself from sibling chess tools by focusing on club data rather than player or leaderboard info.

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

  Usage Guidelines3/5

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

  The description gives a concrete example of usage ('club_id': 'chess-com-developer-community') and notes 'Auth: none needed', which implies when it can be used. However, it doesn't explicitly state when to use this tool vs alternatives, nor does it mention any exclusions or prerequisites beyond the required parameter.

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

• cricketdata_seriesA
  3.5/5.0
  Behavior4/5

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

  The description adds significant context beyond annotations by disclosing that the response shape is from vendor docs and unverified, advising to inspect the actual payload. It also mentions the API key requirement. This is valuable reliability information that annotations don't cover.

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

  Conciseness4/5

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

  The description is well-structured with sections for summary, return shape, notes, example, and auth. While it includes a detailed return shape, this is useful given no output schema. Each part contributes value, though slightly verbose.

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

  Completeness4/5

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

  For a simple list tool with two parameters and no output schema, the description provides a complete picture: what data is returned, the meaning of match counts, a caveat about reliability, an example, and auth requirements. Missing pagination details are partially covered by schema defaults.

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

  Parameters3/5

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

  The input schema fully describes both parameters (offset and search) with concise descriptions. The tool description does not add extra meaning beyond the schema, but since schema coverage is 100%, a baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states that this tool returns series (tours and tournaments) with their match counts and dates. The example 'All series' reinforces that it lists series. It does not explicitly differentiate from cricketdata_series_info, but the scope is evident.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like cricketdata_series_info or other cricketdata tools. The description offers an example and auth note but no usage context or exclusions.

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

• entain_racing_next_racesA
  3.5/5.0
  Behavior4/5

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

  The description adds the return format ('Returns: {category_race_map:{}, race_summaries:{...}}') and explicitly states 'Auth: none needed,' which are useful details beyond the annotations. Since annotations already declare readOnlyHint, openWorldHint, and idempotentHint, the bar is lower; the return shape and auth mention provide meaningful added context, though more details about time windows or ordering would push it higher.

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

  Conciseness4/5

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

  The description is appropriately concise, with a clear purpose statement followed by the return structure and auth note. It is front-loaded and every sentence serves a purpose, though it could potentially elaborate slightly without becoming bloated.

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

  Completeness4/5

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

  For a simple, read-only tool with two well-documented parameters and no output schema, the description provides the essential elements: what it does, the return shape, and auth requirements. It lacks details on time window, ordering, or explicit alternatives, but these are non-critical for a straightforward list operation. It is largely complete for invocation purposes.

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

  Parameters3/5

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

  The input schema already documents both parameters with 100% coverage: 'count' is 'Races per category' and 'categories' is 'JSON array of racing category UUIDs.' The tool description adds no further meaning to these parameters, so the baseline of 3 applies.

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

  Purpose4/5

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

  The description states 'Next races about to jump, grouped per racing category' with a clear verb and resource, and it specifies the grouping behavior and return structure. It distinguishes itself from many racing tools by emphasizing the per-category grouping, but it doesn't explicitly name a sibling alternative, so it falls just 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.

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus similar racing tools like entain_racing_racecard, entain_racing_future_markets, or betr_next5_races. The only usage-related note is 'Auth: none needed,' which addresses prerequisites but not selection criteria, leaving the agent to guess when this is the appropriate choice.

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

• entitysport_match_infoA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare read-only, open-world, and idempotent hints. The description adds valuable context: auth requires a key in ENTITYSPORT_TOKEN, and the response shape is from vendor docs and unverified, advising the agent to inspect the actual payload. This goes beyond the annotations without contradicting them.

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

  Conciseness4/5

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

  The description is well-structured with clear sections: purpose, returns shape, verification note, example, and auth. Each sentence has a purpose, though the returns line is somewhat verbose and could be trimmed without losing value.

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

  Completeness4/5

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

  For a simple one-parameter read-only tool, the description covers the response shape (even if approximate), provides an example, auth requirements, and a caveat about unverified data. The lack of output schema is compensated by the explicit return fields, though the unverified nature limits completeness.

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

  Parameters3/5

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

  Schema coverage is 100% with matchId described as 'Required — part of the URL path.' The description adds an example invocation but no additional semantic meaning beyond what the schema already provides. Baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool returns 'One match with squads, toss and current state,' which conveys the resource and scope. It distinguishes itself from sibling tools like entitysport_matches (list) and match_scorecard/commentary by focusing on match info details, though it lacks an explicit verb like 'Get' or 'Fetch.'

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description only implies single-match usage via 'One match' without mentioning that entitysport_matches lists matches or that scorecard/commentary are separate tools. No exclusions or alternative suggestions are made.

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

• espnfantasy_teamsA
  3.5/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds valuable behavioral context by disclosing authentication behavior ('works without a key; ESPN_FANTASY_COOKIE unlocks more if set') and fully specifying the return payload structure, which annotations do not cover.

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

  Conciseness4/5

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

  The description is well-organized with a summary line, return schema, example, and auth note. It is moderately sized and each section serves a purpose, though the return schema is somewhat lengthy. Overall, it is concise without wasted words.

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

  Completeness4/5

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

  Given the absence of an output schema, the description compensates by providing the full return structure and a concrete example. Combined with complete parameter descriptions and safety annotations, the description is sufficiently complete for an agent to invoke the tool correctly, though it omits details like pagination, error conditions, or rate limits.

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

  Parameters3/5

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

  The input schema provides full documentation for all 4 parameters (100% coverage), including descriptions for leagueId, seasonId, game, and view. The description adds an example with concrete values but does not explain parameters beyond what the schema already states, so the baseline 3 for high schema coverage applies.

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

  Purpose4/5

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

  The description clearly states that the tool provides fantasy teams with records, points for/against, playoff seed and projected rank, and includes a detailed return shape and example. It distinguishes from sibling tools by focusing on team-level data rather than standings, rosters, or matchups, though it lacks an explicit verb like 'retrieves' or 'lists.'

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

  Usage Guidelines2/5

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

  The description does not mention alternative tools or specific conditions for when to use this tool vs siblings. The example implies usage for fetching teams in a league, but there are no exclusions or comparisons to related tools such as espnfantasy_standings or espnfantasy_rosters.

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

• highlightly_nfl_highlightsA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare read-only, idempotent, and open-world behavior. The description adds valuable context beyond annotations by warning that the response shape is unverified from vendor docs and advising inspection of the actual payload. It also discloses the need for a personal API key, which is not in the schema or annotations.

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

  Conciseness4/5

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

  The description is well-structured and front-loaded with the core purpose, followed by response shape, caveat, example, and auth. Each section serves a purpose. It is slightly longer than necessary but every sentence contributes useful information, especially the vendor-doc caveat.

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

  Completeness4/5

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

  Despite the lack of an output schema, the description provides an approximate return shape, pagination indicator, an example call, and auth requirements. The caveat about unverified shape is important for the agent to set expectations. It could improve by noting when no parameters are provided, but this is a reasonably complete description for a simple read tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema carries the full weight of parameter semantics. The description adds only an example using 'date', without elaborating on limit, matchId, or leagueId behavior beyond their schema descriptions. This meets the baseline but does not exceed it.

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

  Purpose4/5

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

  The description clearly identifies the resource ('American-football highlight clips') and indicates retrieval via 'Returns:'. It distinguishes the sport from sibling highlight tools like highlightly_soccer_highlights. However, it lacks an explicit verb like 'get' or 'list', making it slightly less direct than ideal.

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

  Usage Guidelines2/5

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

  The description provides an example query and notes the auth requirement, but gives no explicit guidance on when to use this tool versus alternatives or any exclusions. It does not clarify whether certain parameters are preferred for common use cases (e.g., date vs matchId).

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

• kalshi_milestonesA
  3.5/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, establishing a safe read operation. The description adds valuable context by specifying the return structure (cursor and milestone fields) and explicitly stating no auth is needed, which goes beyond the annotations.

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

  Conciseness4/5

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

  The description is concise and front-loaded with the core definition, then provides the return format and auth status in a structured manner. Every line contributes useful information, though the auth note is trivial but acceptable.

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

  Completeness4/5

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

  For a read-only list operation with optional parameters and no output schema, the description provides adequate context: what the tool returns, the response shape, and auth. It lacks explicit pagination guidance, but the schema covers cursor semantics. Overall, it is sufficiently complete for a simple listing tool.

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

  Parameters3/5

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

  The input schema has 100% coverage with descriptions for all four parameters (limit, cursor, category, minimum_start_date). The tool description does not add any additional parameter-level detail, so it is at the baseline for full schema coverage.

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

  Purpose4/5

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

  The description clearly defines what milestones are (dated catalysts linked to event tickers) and implies a retrieval operation. It distinguishes itself from sibling Kalshi tools by focusing on the milestone concept. However, it lacks an explicit verb like 'list' or 'get', which would make the purpose even more direct.

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

  Usage Guidelines2/5

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

  There is no explicit guidance on when to use this tool versus other Kalshi tools (e.g., kalshi_events, kalshi_markets). The description only implies usage by defining the resource. No alternatives or exclusions are mentioned.

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

• mlb_free_agentsA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds value by disclosing the exact return structure ({freeAgents:[...]}) and stating 'Auth: none needed,' which are behavioral details not captured by the annotations. 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.

  Conciseness4/5

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

  Three compact sentences cover purpose, return format, and auth requirement, with no filler. Front-loaded with the key purpose statement. A minor bracket typo in the return shape ('position]}]') slightly detracts.

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

  Completeness4/5

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

  For a simple query tool with rich annotations (read-only, idempotent, open-world), full schema coverage, and explicit return format in the description, this is largely complete. The main gap is lack of pagination/result-count behavior, but this is acceptable for a straightforward list tool. Auth requirement and return shape compensate for the missing output schema.

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

  Parameters3/5

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

  All three parameters (season, order, leagueId) have descriptions in the schema with 100% coverage, so the description need not repeat them. The description's 'for a season' aligns with the required season parameter, and leagueId's schema description ('103=AL, 104=NL') already provides semantic meaning. The description adds no parameter-specific detail beyond the schema.

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

  Purpose4/5

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

  The description clearly identifies the tool's function: retrieving free agents for a season with player and from/to-team signing info. The resource (free agents) and scope (season) are stated, though the verb is implied ('returns') rather than explicit. It does not explicitly distinguish from similar MLB info tools like mlb_transactions.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives such as mlb_transactions or mlb_people_changes. The 'for a season' phrase provides scope context but no exclusions, prerequisites, or alternative recommendations.

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

• mlb_game_win_probabilityA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the bar is lower. The description adds valuable context by stating 'Auth: none needed' and clearly outlining the return format as a top-level array with specific fields. This goes beyond the annotations and helps set expectations.

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

  Conciseness4/5

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

  The description is concise and front-loaded, with the main purpose stated first, followed by return format and auth. The inclusion of 'Also answers this: espn_core_call' is cryptic and somewhat distracting, preventing a perfect score for structure.

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

  Completeness4/5

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

  Despite lacking an output schema, the description explicitly lists the return fields, which is sufficient for a simple read-only tool. Combined with the annotations and parameter schema, the description covers auth, data shape, and safety. The only minor gap is the ambiguous cross-reference to espn_core_call, which adds slight confusion rather than completeness.

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

  Parameters3/5

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

  Schema description coverage is 100% for both parameters (gamePk and timecode), so the schema already fully documents them. The description does not add any additional meaning or context for the parameters, such as format examples or relationships between them. Thus, it neither improves nor harms the schema's clarity.

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

  Purpose4/5

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

  The description clearly identifies the tool as providing a win-probability time series with leverage index after each play. It specifies the return fields (atBatIndex, homeTeamWinProbability, awayTeamWinProbability, leverageIndex, homeTeamWinProbabilityAdded), which distinguishes it from other MLB tools like mlb_boxscore or mlb_playbyplay. However, it lacks an explicit verb like 'get' or 'retrieve', so it stops short of a perfect 5.

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

  Usage Guidelines2/5

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

  No explicit guidance is given on when to use this tool rather than alternatives. The only cross-reference is the cryptic statement 'Also answers this: espn_core_call', which is ambiguous and does not provide clear when-to-use or when-not-to-use criteria. The reader must infer usage solely from the data description.

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

• pandascore_leaguesA
  3.5/5.0
  Behavior4/5

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

  The annotations (readOnlyHint, openWorldHint, idempotentHint) already establish the safety profile. The description adds valuable context beyond annotations: the requirement for an API key in PANDASCORE_TOKEN and the important warning that the return shape is from vendor docs and unverified. This helps an agent know the payload may differ, though error behavior and rate limits are not addressed.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the definition, followed by the return shape, a critical caveat, an example, and auth note. Every part is relevant, though the example is minimal and the structure could be tightened. It earns a 4 for efficiency and clear organization.

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

  Completeness4/5

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

  For a simple list tool with comprehensive schema descriptions and safety annotations, the description is reasonably complete. It includes the expected return shape (with a caveat), auth requirements, and the resource definition. However, it lacks an explicit statement of the operation (list/get) and does not explain how the optional filters affect results, but given the tool's simplicity this is adequate.

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

  Parameters3/5

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

  The input schema already provides descriptions for all three parameters (100% coverage). The description does not add any additional explanation about the parameters beyond what the schema provides, so the baseline of 3 applies. It does not clarify ambiguous terms like 'Title slug' for filter_videogame.

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

  Purpose4/5

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

  The description defines leagues as 'recurring competitions tournaments belong to' and provides the return shape, making it clear this is a list/fetch operation for leagues. It distinguishes from siblings like pandascore_tournaments by explaining the relationship, but lacks an explicit verb (e.g., 'List' or 'Get'), so it doesn't fully meet the 5 criterion.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives such as pandascore_tournaments or pandascore_series. The description only defines the resource and returns a shape; it does not state when to choose this tool, any prerequisites, or exclusions. The 'Example: All leagues' is too vague to serve as usage guidance.

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

• pl_squadA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context like 'Auth: none needed' and the exact return shape, but it does not discuss pagination, data completeness, or error behavior, which would add more value.

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

  Conciseness4/5

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

  The description is short and front-loaded with the core purpose. There is minor redundancy between the first sentence listing player fields and the Returns block repeating those fields, but overall it is compact and well-organized.

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

  Completeness4/5

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

  With no output schema, the description provides a clear return structure including the players array and its fields, plus auth information. For a simple read-only look-up with three well-documented parameters, this is sufficiently complete, though it could clarify semantics of 'dates' and 'team'.

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

  Parameters3/5

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

  Schema description coverage is 100% with clear descriptions for cid, sid, and tid, so the baseline is 3. The tool description adds no parameter-specific meaning beyond what the schema already provides.

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

  Purpose5/5

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

  The description clearly states the tool returns a full squad for a team in a season, listing the player fields included. It differentiates from siblings like pl_teams or pl_team by focusing specifically on the squad/roster with detailed player attributes.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives such as pl_players or pl_team. The description implies usage from the purpose but does not state when to prefer it over other squad/player tools or mention any exclusions.

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

• polymarket_holdersA
  3.5/5.0
  Behavior4/5

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

  The description adds the return structure and authentication requirement, which go beyond the annotations (readOnlyHint, openWorldHint, idempotentHint). It discloses the top-level array format and that no auth is needed, enriching the agent's understanding. 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.

  Conciseness5/5

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

  The description is extremely concise and well-structured with 'Returns:' and 'Auth:' sections. It is front-loaded with the purpose and contains no unnecessary content.

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

  Completeness3/5

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

  The tool is simple, and the description provides a return template, but 'top holders' is not defined (e.g., by amount) and the '…' in the return shape leaves ambiguity. Since there is no output schema, the description should clarify these details more fully.

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

  Parameters3/5

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

  Schema description coverage is 100%: both 'market' (Condition id) and 'limit' (Max holders per token) are fully described in the schema. The description text does not add further parameter semantics, so baseline 3 applies.

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

  Purpose4/5

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

  The description clearly states it provides top holders of a market's outcome tokens, which is specific and distinguishes it from sibling Polymarket tools like polymarket_book or polymarket_trades. However, it lacks an explicit verb such as 'List' or 'Get', though the 'Returns:' section makes the retrieval intent clear.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives. There is no mention of alternatives, exclusions, or context for choosing it over other Polymarket data tools. The only extra note is 'Auth: none needed,' which is not usage direction.

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

• polymarket_marketA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds 'Auth: none needed' and the return object shape, which provide some context, but there is no mention of error handling, latency, or what happens for invalid ids.

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

  Conciseness4/5

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

  The description is mostly concise and front-loaded, with the purpose in the first sentence and a compact return shape listing. However, the final 'Also answers this: kalshi_market.' sentence is ambiguous and could mislead, preventing a perfect score.

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

  Completeness4/5

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

  For a single-parameter tool with no output schema, the description provides a reasonable amount of context: it lists the return fields inline, notes no auth required, and specifies the id source indirectly. It lacks explanation of the events array or potential missing fields, but overall it is adequate.

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

  Parameters3/5

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

  Schema coverage is 100% and the 'id' parameter already has a rich description (Gamma market id from polymarket_markets, required, URL path part). The tool description merely repeats 'by Gamma id' without adding new parameter syntax or format details, so it does not go beyond the schema.

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

  Purpose4/5

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

  The description clearly states that this tool retrieves a single market's full detail by Gamma id, listing key fields like question, outcomes, prices, and CLOB token ids. It distinguishes from the sibling 'polymarket_markets' (plural) by the 'One market' phrasing, though it does not explicitly name an alternative.

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

  Usage Guidelines3/5

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

  The usage is implied: when you have a Gamma id and need full market detail. However, there are no explicit 'when to use' or 'when not to use' instructions, and the cryptic 'Also answers this: kalshi_market.' line adds confusion rather than clear guidance.

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

• sleeper_leagueA
  3.5/5.0
  Behavior4/5

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

  The description adds valuable context beyond the annotations by showing the full response schema (e.g., league_id, scoring_settings, settings fields), providing an example league_id, and noting that no authentication is needed. This helps set expectations for the tool's behavior without contradicting the readOnlyHint or idempotentHint.

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

  Conciseness4/5

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

  The description is well-structured with a brief summary, a 'Returns' section, an example, and an auth note. It is information-dense without being unnecessarily verbose, though the return schema block is somewhat long. Overall, it is concise and easy to scan.

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

  Completeness4/5

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

  Given there is no output schema, the description effectively compensates by providing a detailed return structure and an example, which is sufficient for understanding what the tool returns. It could be even more complete with notes on error handling or edge cases, but it is largely complete for its purpose.

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

  Parameters3/5

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

  The input schema already provides a thorough description of the single parameter, league_id, including where to find it. The tool description adds an example value but no further semantic detail. Since schema_description_coverage is 100%, the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly outlines what the tool does by listing the league configuration aspects it returns (scoring rules, roster slots, playoff format, etc.) and provides a detailed return structure. This distinguishes it from sibling tools like sleeper_league_rosters, though it lacks an explicit verb like 'get' or 'fetch'.

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

  Usage Guidelines2/5

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

  No explicit guidance is given on when to use this tool versus alternatives. Given the large number of Sleeper sibling tools, mentioning that this is for league configuration specifically and using others for rosters or users would have been helpful. The usage is implied by the return fields but not stated.

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

• sportmonks_teamsA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare the tool read-only, open-world, and idempotent, and the description adds valuable context beyond this: the need for a SPORTMONKS token, the unverified vendor-documented response shape, and the explicit warning to inspect the actual payload before relying on field names. This additional transparency about data reliability and authentication is genuinely useful.

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

  Conciseness4/5

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

  The description is well-structured: it opens with a concise summary, then gives a sample return shape, a critical caveat about unverified documentation, and an auth note. The 'Example: Teams on your plan' line is cryptic and adds little, but overall the length is justified and the text is front-loaded with the most important information.

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

  Completeness4/5

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

  Given that there is no output schema, the description compensates by providing a detailed return shape, pagination info, authentication requirements, and a caveat about data reliability. This is fairly complete for a list/read-only tool. The main gap is the unexplained 'search or season' capability, which leaves the tool's full usage surface ambiguous.

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

  Parameters3/5

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

  Input schema has 100% parameter coverage with descriptions for page, include, and per_page, so a baseline of 3 applies. The description does not add meaningful parameter semantics—in fact, it introduces a 'search/season' concept not represented in the schema, which could mislead an agent into expecting parameters that do not exist. No additional value is provided beyond the schema's already minimal descriptions.

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

  Purpose4/5

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

  The description identifies the tool as retrieving clubs/teams from Sportmonks, clearly distinguishing it from sibling tools like sportmonks_leagues or sportmonks_players. However, the phrase 'by search or by season' is vague and does not specify what search terms or season identifiers are accepted, leaving some ambiguity about the exact scope.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives. It mentions two modes ('search' and 'season') but does not explain how they differ or when to prefer one over the other, and there is no mention of alternative tools or exclusion criteria. The only practical guidance is the auth requirement, which is operational rather than usage-oriented.

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

• tab_trending_propsA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description adds value with the auth behavior: 'works without a key; TAB_CLIENT_ID or TAB_CLIENT_SECRET unlocks more if set.' This reveals additional context beyond annotations, but does not clarify what 'unlocks more' means (e.g., data richness, rate limits). 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.

  Conciseness5/5

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

  The description is extremely concise, containing just three lines: purpose, return shape, and auth. Every sentence serves a distinct purpose—identifying the resource, hinting at the output structure, and clarifying authentication. No wasted words or redundancy.

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

  Completeness3/5

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

  Given there is no output schema, the description partially compensates by listing example fields, but it leaves gaps: the meaning of 'trending' is undefined, and no details on result limits, pagination, or how the jurisdiction parameter affects results. The tool is simple (one optional param), but the description could more fully address the response and parameter impact to be complete.

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

  Parameters3/5

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

  The only parameter, 'jurisdiction', is fully described in the schema as 'State jurisdiction.' The description does not add any additional meaning, such as allowed values, impact on results, or examples. With schema coverage at 100%, the baseline is 3, and the description adds nothing beyond that baseline.

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

  Purpose5/5

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

  Description clearly states it returns 'Trending sports propositions / bets across the book' and provides a partial return shape. The verb 'trending' is specific, and 'across the book' distinguishes it from sport-specific or event-specific tools. The mention of fields like sportName and matchId further clarifies the resource.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus the many sibling tools (e.g., tab_match_markets, tab_featured_events). The auth note implies prerequisites but does not address alternative usage contexts or exclusions. The agent is left to infer that this is for overarching trending props without differentiation.

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

• yahoo_league_transactionsA
  3.5/5.0
  Behavior3/5

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

  The annotations indicate readOnly, openWorld, and idempotent, and the description does not contradict them. It adds a caveat that the return shape is from vendor docs and may be unverified, which is helpful transparency. However, it does not elaborate on other behavioral aspects like error handling or data freshness beyond that, so it provides only moderate added value 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.

  Conciseness4/5

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

  The description is well-structured with clear sections for the summary, return shape, example, and auth note. It contains necessary details without being excessively verbose. The inclusion of the return shape and example is useful, though the return shape description is somewhat lengthy and could be trimmed, but overall it is concise enough for its purpose.

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

  Completeness4/5

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

  The description provides the core functionality, expected output shape, an example request, and authentication requirements. It also includes a caution about the unverified vendor documentation. Given the tool's simplicity (two parameters) and that annotations cover read-only/idempotent nature, the description is fairly complete. It lacks details on error scenarios, but that is minor given the clarity of the rest.

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

  Parameters3/5

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

  The input schema already provides descriptions for both parameters (format and leagueKey), and the tool description does not add further meaning beyond what is already in the schema. The parameters are straightforward, and the description's mention of leagueKey in the example reinforces its role, but it does not provide additional semantic depth that the schema lacks. Since schema coverage is 100%, the baseline score of 3 applies.

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

  Purpose4/5

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

  The description clearly states the tool's function: 'Adds, drops, waiver claims and trades across the league — who is doing what.' This unambiguously indicates it retrieves league transaction data, and it is distinguishable from other Yahoo tools which focus on different aspects (e.g., standings, teams, players). It could be more explicit by using 'Get' or 'Fetch', but the meaning is clear.

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

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool over alternatives, but it is implicitly clear that it is for transactions. There are no obvious sibling tools for transactions, so the usage context is implied by the name and description. However, it lacks explicit guidance on use cases or when not to use it, so it falls short of a higher score.

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

• afl_clubs_listA
  3.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds context beyond annotations by specifying the return shape ({clubs:[...]}) and auth requirement (none needed), which is useful for invocation.

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

  Conciseness5/5

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

  The description is extremely concise, delivering purpose, return structure, and auth in three short lines. It is front-loaded and contains no filler or redundant information.

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

  Completeness4/5

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

  For a simple list tool, the description is nearly complete: it covers what, returns, and auth. The schema handles pagination parameters, and annotations cover safety. The only missing piece is explicit guidance on when to use this over sibling tools, but that is not critical given the low complexity.

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

  Parameters3/5

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

  Schema coverage is 100% with descriptive parameter names and clear descriptions (page: 'Zero-based page number.', pageSize: 'Rows per page.'). The tool description adds no additional parameter meaning, so baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool lists AFL/AFLW clubs with a specific resource and a count of 32. It does not explicitly differentiate from the sibling afl_teams_list, which could be similar, but the core purpose is unambiguous.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives such as afl_teams_list or afl_club_get, and no exclusions are mentioned. For a simple read-only list, this is a gap but not fatal given the name implies its scope.

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

• balldontlie_epl_gamesA
  3.6/5.0
  Behavior4/5

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

  The description adds valuable context beyond the readOnly/idempotent annotations: it explicitly warns that the return shape is unverified and approximate, provides the auth key requirement, and advises inspecting the actual payload. This is honest and helpful, raising the score above baseline.

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

  Conciseness4/5

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

  The description is well-organized with clear sections (Returns, NOTE, Example, Auth) and no filler. The caveat about unverified shape is necessary but makes it slightly longer than the minimum, hence a 4 rather than 5.

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

  Completeness3/5

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

  The return shape and auth requirements are covered, which is important given there is no output schema. However, the description does not explain behaviors such as what happens when no filters are provided, how filters combine, or the meaning of the openWorldHint. These gaps leave the tool contextually incomplete for a 5-parameter API.

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

  Parameters3/5

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

  Schema coverage is 100% with each parameter individually described, so the baseline is 3. The description contributes only an example using 'season' and a mention of pagination via 'next_cursor', but does not add substantial meaning beyond what the schema already explains.

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

  Purpose5/5

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

  The phrase 'Premier League fixtures and results' is a clear, specific statement of purpose with a verb and resource. It distinguishes this tool from sibling balldontlie tools for other leagues (NBA, NFL, MLB) and other Premier League data tools.

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

  Usage Guidelines2/5

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

  No explicit guidance is given for when to use this tool versus alternatives. The description does not mention any exclusions or compare with the many pl_* sibling tools, so the agent must infer usage solely from the name and the phrase 'Premier League fixtures and results.'

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

• balldontlie_nba_gamesA
  3.6/5.0
  Behavior4/5

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

  Annotations already state readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context: the exact return shape, the pitfall that the away team is 'visitor_team' not 'away_team', a clear warning that the shape is unverified and should be inspected, and the need for an API key. This goes beyond the annotations and helps the agent avoid misinterpreting payloads.

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

  Conciseness4/5

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

  The description is structured into distinct sections (what it does, return shape, caveats, example, auth). Each sentence serves a purpose, and the necessary vendor-doc warnings are included without being overly verbose. Slightly longer than ideal, but the content justifies the length.

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

  Completeness4/5

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

  Without an output schema, the description effectively provides the return shape and warns about its unverified nature. It also covers authentication and gives a usage example. However, it does not explain pagination behavior (e.g., how to use 'cursor' with 'meta.next_cursor') or whether filters can be combined, leaving some gaps for a complex data-retrieval tool.

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

  Parameters4/5

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

  The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds a concrete example for the 'dates' parameter and clarifies the intended usage of 'season' and 'team' conceptually, enhancing the schema's factual descriptions.

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

  Purpose4/5

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

  The description clearly states 'NBA games by date, season or team', identifying the resource (NBA games) and the main filter dimensions. It does not explicitly differentiate from sibling tools like apisports_basketball_games or sportsdataio_nba_games_by_date, but the provider-specific name and scope make it unambiguous enough.

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

  Usage Guidelines2/5

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

  There is no explicit guidance on when to use this tool versus alternatives, nor any mention of when not to use it. The example shows a simple date query, which implies usage, but the description lacks any comparative direction among the many NBA games tools in the sibling list.

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

• betr_featured_racingA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful context about the return shape and the editorial/promotional nature, but does not explain ordering guarantees or how carousel order is determined.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core purpose, then gives the return shape and auth requirement. Every sentence adds value without redundancy.

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

  Completeness5/5

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

  For a zero-parameter, read-only tool with strong annotations, the description provides enough detail: it states the data source context, the exact return fields, and auth. No output schema exists, so the inline return type fulfills that need.

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

  Parameters4/5

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

  With zero parameters and 100% schema coverage, the schema already fully describes the input space. The description correctly omits parameter details, earning the baseline for no-parameter tools.

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

  Purpose4/5

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

  The description identifies the tool as returning editorially featured racing events with carousel order and promotion titles, which clarifies the resource. It is distinct from sibling racing tools in mentioning editorial curation, though it lacks an explicit 'get/list' verb phrasing.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives like betr_todays_races or pointsbet_racing_featured is provided. The only usage-related note is 'Auth: none needed,' which is not a selection criterion.

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

• datagolf_hist_dfs_pointsA
  3.6/5.0
  Behavior4/5

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

  Annotations already establish read-only, idempotent, and open-world behavior. The description adds valuable context beyond annotations by specifying the exact return structure and the need for a DATAGOLF_KEY for authentication. It does not contradict any annotations.

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

  Conciseness5/5

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

  The description is succinct and front-loaded: a one-sentence purpose, a compact return schema, and a single auth note. Every sentence earns its place with no redundancy or filler.

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

  Completeness4/5

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

  Even without an output schema, the description provides the full return shape, which is essential for the agent. It also covers auth. However, it doesn't explain the relationship to datagolf_hist_dfs_event_list for discovering valid event IDs, which is a minor gap given the tool's moderate complexity.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all parameters. The description adds little about parameter behavior, only referencing 'past event' which loosely maps to event_id and year, but this is sufficient given the schema's thoroughness.

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

  Purpose4/5

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

  The description clearly states the tool provides 'Historical DFS points + salary + ownership per player for a past event', which identifies the specific resource and data returned. It is distinct from siblings like datagolf_hist_rounds or datagolf_hist_results by focusing on DFS-specific data, though it doesn't explicitly name alternative tools.

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

  Usage Guidelines2/5

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

  The description gives minimal usage context, only implying it is for past events. It does not mention when to use this instead of related tools like datagolf_hist_dfs_event_list or datagolf_fantasy_projections, nor does it note prerequisites such as obtaining an event_id from another tool.

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

• entain_cms_entriesA
  3.6/5.0
  Behavior4/5

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

  The description adds valuable behavioral details beyond the annotations: it states 'Auth: none needed' and defines the exact return structure ({sys, total, skip, limit, items, includes}). Annotations already declare read-only and idempotent behavior, so the description does not need to repeat those. No contradiction.

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

  Conciseness5/5

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

  The description is concise and well-structured: one-line resource definition, a Returns section, an Example, and an Auth note. Every element adds value with no redundancy or wasted words.

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

  Completeness4/5

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

  For a simple read-only query tool, the description covers essential context: what it does, return format, an example query, and auth requirements. Combined with annotations and full schema coverage, no critical information is missing. It does not mention pagination defaults or error behavior, but those are not essential for a basic filtered list.

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

  Parameters3/5

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

  Schema coverage is 100%, with each parameter described as 'Contentful CDA' fields. The description adds a concrete example (content_type=promotions, limit=20) that illustrates usage but does not explain parameters beyond what the schema already provides. Baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly identifies the resource as 'Contentful CMS entries' with specific content types (promotions, major-event nav) and access method (www CDN proxy). While it lacks an explicit verb like 'retrieve' or 'list', the naming and content make the purpose unambiguous. It differentiates from sibling tools by specifying Contentful CMS entries.

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

  Usage Guidelines2/5

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

  The description provides an example ('Active promotions') but no explicit guidance on when to use this tool versus alternatives like entain_featured_slider or entain_quicklinks_list. There is no mention of exclusions or conditions that would favor another tool.

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

• entain_event_market_type_group_mapsA
  3.6/5.0
  Behavior4/5

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

  Annotations declare read-only, idempotent, and open-world hints, lowering the transparency burden. The description adds value by specifying the dedup behavior, the exact return shape, and that no authentication is required.

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

  Conciseness5/5

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

  The description is compact and front-loaded, with the core purpose in the first sentence, followed by return type and auth note. Every line adds distinct information with no filler.

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

  Completeness4/5

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

  For a single-parameter lookup tool with rich annotations, the description covers purpose, return shape, and auth. It doesn't explicitly explain that the result is filtered by category_id, but the schema and return type make this reasonably clear.

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

  Parameters3/5

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

  Schema coverage is 100%, with category_id documented as 'Sport category UUID.' The description itself adds no parameter-level detail, but the schema already fully explains the lone parameter, so the baseline of 3 applies.

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

  Purpose4/5

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

  Description identifies the resource as a join table between market types and market-type groups, with a clear dedup-by-pair qualifier. It distinguishes by focusing on the mapping relationship rather than the groups themselves, though it lacks an explicit action verb like 'list' or 'get'.

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

  Usage Guidelines2/5

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

  No guidance is given about when to use this mapping tool versus alternatives such as entain_event_market_type_groups or entain_event_market_rules. The description states what it returns but not the scenarios or exclusions.

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

• entain_event_market_type_groupsA
  3.6/5.0
  Behavior4/5

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

  Annotations already establish read-only/idempotent behavior, and the description adds valuable behavioral context: no authentication required, the exact return shape, and the priority ordering of results. This goes beyond the baseline and gives the agent actionable information.

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

  Conciseness5/5

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

  Two concise sentences immediately state the tool's purpose, return structure, and auth requirement, with no filler or redundant restatements of the schema.

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

  Completeness4/5

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

  For a simple read-only lookup with one well-documented parameter and an inline return format, the description is sufficiently complete for an agent to select and invoke the tool. It could benefit from an example or a note about related Entain tools, but nothing essential is missing.

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

  Parameters3/5

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

  The only parameter category_id is fully described in the schema as 'Sport category UUID', so the description adds no extra meaning. Since schema coverage is 100%, the baseline of 3 applies and there is no additional guidance on how to obtain or format the value.

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

  Purpose4/5

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

  The description clearly states that the tool provides market-tab group definitions for a sport category and notes the ordering behavior. However, it lacks an explicit verb like 'get' or 'list' and does not differentiate from the similarly named sibling entain_event_market_type_group_maps, which prevents a perfect score.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives, what queries it is best suited for, or any prerequisites beyond the schema. The description simply states what it returns without usage context.

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

• espnfantasy_matchupsA
  3.6/5.0
  Behavior4/5

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

  The annotations already mark the tool as readOnly, openWorld, and idempotent; the description adds that authentication is optional and that setting ESPN_FANTASY_COOKIE 'unlocks more'. It also details the return JSON structure, providing transparency about what the tool will output.

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

  Conciseness3/5

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

  The description is relatively brief but includes multiple components: purpose, return schema, example, auth, and a sibling pointer. The 'Also answers this' line is ambiguous and could be omitted or clarified, and the example could be more integrated.

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

  Completeness4/5

  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 showing the return structure with example fields like winner, home, away, and pointsByScoringPeriod. It covers auth and gives an example call. However, it doesn't mention potential limitations such as whether playoff matchups are included or how to handle a full season's data size.

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

  Parameters3/5

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

  The input schema already documents all four parameters with 100% coverage, so the description's example with concrete values (ffl, 2018, 1234) is helpful but not necessary. It does not add significant new meaning beyond what the schema provides, hence a baseline score.

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

  Purpose4/5

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

  The description states 'Full season schedule of head-to-head fantasy matchups with each side's total and per-period points,' clearly indicating the tool returns a comprehensive matchup schedule. It distinguishes itself from espnfantasy_matchup_score or boxscore by focusing on the full season schedule. However, it lacks a direct verb like 'get' or 'list', making it slightly less explicit than ideal.

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

  Usage Guidelines3/5

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

  The description includes a pointer to 'sleeper_matchups, sleeper_playoff_bracket' under 'Also answers this,' suggesting alternatives for the Sleeper platform, but it does not provide explicit when-to-use or when-not-to-use guidance. The example call shows typical use, but the decision framework between this and sibling tools is not fully spelled out.

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

• footballdataorg_competitionsA
  3.6/5.0
  Behavior3/5

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

  The description provides a detailed return shape, notes the verification status, and explains the 'plan' field, going beyond annotations. However, it directly contradicts itself by stating 'works without a key' in the first line but later saying 'Auth: needs your own key in FOOTBALL_DATA_ORG_KEY.' This self-contradiction reduces transparency.

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

  Conciseness3/5

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

  The description contains a lot of valuable detail, but it is somewhat disorganized with a redundant 'VERIFIED live' claim paired with a later note that the shape is unverified. The 'Example: All competitions' line is vague and adds little value. The contradictory auth statements also hurt clarity.

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

  Completeness4/5

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

  For a tool with one optional parameter and no output schema, the description covers the return shape, plan semantics, verification caveat, and auth expectations. It is reasonably complete, though the auth contradiction leaves some ambiguity about whether a key is truly required.

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

  Parameters3/5

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

  The parameter 'areas' is fully described in the schema with a clear reference to footballdataorg_areas. The description adds no additional meaning about this parameter, so the baseline of 3 applies given high schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool returns every competition in the API along with its code and current season, with a concrete return shape. It distinguishes itself from the singular sibling footballdataorg_competition by explicitly using 'Every competition' and from other providers like pl_competitions by naming the API.

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

  Usage Guidelines3/5

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

  The description gives useful context about the free tier (TIER_ONE only) and that the tool works without a key, but it does not explicitly state when to use this tool instead of alternatives like footballdataorg_competition. I'm implied by 'Every competition' but no direct comparison or exclusion is provided.

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

• kalshi_mve_collectionA
  3.6/5.0
  Behavior4/5

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

  Annotations already establish read-only, idempotent, and open-world behavior. The description adds useful context by stating 'Auth: none needed' and specifying the return structure, which is valuable given the absence of an output schema. No contradictions 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.

  Conciseness5/5

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

  The description is extremely concise, with one sentence for purpose, one for return payload, and one for authentication. Every element earns its place with no redundancy or padding.

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

  Completeness4/5

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

  For a simple read-only single-item lookup, the description provides adequate context: it states the input (ticker), the return shape, and the auth requirement. It does not discuss error scenarios or edge cases, but these are less critical given the low complexity and the presence of schema and annotations.

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

  Parameters3/5

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

  The input schema provides 100% description coverage for the single collectionTicker parameter, including the fact that it is required and part of the URL path. The tool description does not add any additional parameter-level semantics beyond what the schema already states.

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

  Purpose4/5

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

  The description "One multivariate event collection by ticker" clearly identifies the resource and retrieval action, and its singular form distinguishes it from the plural sibling tool kalshi_mve_collections. However, it lacks an explicit verb like 'get' or 'fetch,' which makes the intended operation slightly less direct.

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

  Usage Guidelines2/5

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

  There is no explicit guidance on when to use this tool versus alternatives. The singular/plural distinction with kalshi_mve_collections hints at a specific use case, but no when/when-not criteria or alternative recommendations are provided.

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

• kalshi_mve_collectionsA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds 'Auth: none needed' and explains the market-to-collection relationship, but provides no additional behavioral details like pagination behavior or filtering semantics. No annotation contradiction.

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

  Conciseness5/5

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

  The description is compact and well-organized: a one-sentence purpose, a structured return shape, and an auth note. No filler or redundant information.

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

  Completeness4/5

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

  Combined with good annotations and full schema coverage, the description provides enough context: it names the resource, explains the relationship to markets, lists the return fields, and notes auth requirements. It could mention pagination/filtering behavior, but that is not essential for a moderate-complexity list tool.

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

  Parameters3/5

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

  The schema has 100% description coverage for all 4 parameters (limit, cursor, status, series_ticker). The description adds no extra parameter-level semantics, so it stays at the baseline score of 3.

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

  Purpose4/5

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

  The description identifies the resource as 'Multivariate event collections' and clarifies they are 'parlay-style combo products' tied to KXMVE* markets via mve_collection_ticker. However, it lacks an explicit verb like 'List' or 'Get', so the action must be inferred from the return shape.

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

  Usage Guidelines3/5

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

  It gives useful context that a market's mve_collection_ticker points here, implying this tool is for looking up parent collections of KXMVE markets. But it does not explicitly distinguish this from the sibling tool kalshi_mve_collection or state when this tool should be preferred over alternatives.

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

• laliga_roundsA
  3.6/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond the annotations by stating the auth requirement: 'works without a key; LALIGA_SUBSCRIPTION_KEY unlocks more if set.' It also discloses the return structure. These details complement the readOnlyHint, openWorldHint, and idempotentHint annotations without contradicting them.

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

  Conciseness5/5

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

  The description is compact and efficient: a one-line purpose statement, a concise return type block, and an auth note. Every element earns its place, with no redundancy or irrelevant detail.

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

  Completeness4/5

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

  For a simple read-only tool with one parameter, the description covers the purpose, return shape (compensating for the lack of an output schema), and auth behavior. It does not explain edge cases like invalid slug handling, but given the schema covers the parameter and annotations confirm safety, it is sufficiently complete.

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

  Parameters3/5

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

  The input schema already covers the single parameter 'slug' with 100% description coverage, explaining it as 'Subscription slug. Required — part of the URL path.' The description provides no additional parameter semantics, so the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly identifies the resource: "Rounds / matchweeks structure for a season" and includes the return shape, distinguishing it from sibling tools like laliga_matches or laliga_standing. However, it lacks an explicit verb such as 'get' or 'list', opening with a noun phrase rather than a direct action.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description does not mention scenarios where this is preferred over laliga_matches, laliga_competition, or other related tools, nor does it state any exclusions. The only extra context is auth behavior, which is not usage guidance.

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

• mlb_divisionsA
  3.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by explicitly stating the return shape ('Returns: {divisions:[...]}') and that no authentication is needed, providing useful behavioral details 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.

  Conciseness5/5

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

  The description is very brief and well-structured: a summary line, a returns line, and an auth note. Each element is necessary and there is no redundancy or filler.

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

  Completeness4/5

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

  For a simple catalogue tool, the description provides the output schema and auth requirements, and the schema covers parameter purposes. It lacks parameter usage examples, but the simplicity of the tool and the presence of annotations make it sufficiently complete.

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

  Parameters3/5

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

  Input schema covers all three parameters with basic descriptions ('Filter by sport', etc.), which gives 100% schema coverage and a baseline of 3. The tool description does not elaborate on parameter semantics, leaving the schema's generic filters as the only guidance.

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

  Purpose4/5

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

  The description identifies the resource as a division catalogue with specific content (AL/NL East, Central, West) and league/sport links, distinguishing it from sibling tools like mlb_teams or mlb_leagues. However, it lacks an explicit verb like 'List' or 'Get,' relying on the noun 'catalogue' to imply the action.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives such as mlb_conferences or mlb_leagues. The description simply states what it returns without any context on typical use cases or exclusions.

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

• mlb_game_context_metricsA
  3.6/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond the annotations: it states the exact return object shape and explicitly notes that no authentication is needed. It also clarifies the temporal scope ('current/most-recent state'), which helps set expectations. With readOnlyHint and idempotentHint already present, this extra context is sufficient.

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

  Conciseness5/5

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

  The description is compact and well-structured: purpose in the first sentence, return shape in the second, and auth in the third. Every sentence contributes value without redundancy or filler, and the key information is front-loaded.

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

  Completeness4/5

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

  For a read-only tool with full schema coverage and clear annotations, the description covers the return contract, temporal scope, and auth requirement. The main gap is the lack of guidance on how this tool relates to overlapping siblings, but the core context is sufficiently complete for basic usage.

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

  Parameters3/5

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

  The input schema already fully documents both parameters (gamePk required, timecode optional) with descriptions, so the baseline applies. The description's mention of 'current/most-recent state' hints at timecode semantics but does not add meaningful extra detail beyond the schema.

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

  Purpose4/5

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

  The description clearly states that the tool provides context metrics for a game, listing specific metric types (leverage, win-probability, run-expectancy) and scope ('current/most-recent state'). While it is clear, it does not explicitly differentiate from the sibling tool mlb_game_win_probability, which likely overlaps.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives like mlb_game_win_probability or mlb_live_feed. It neither specifies use cases nor exclusions, leaving the agent to infer the appropriate context from the name and return fields.

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

• mlb_game_uniformsA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds a helpful 'Auth: none needed' note and a return structure example, but discloses no other behavioral traits such as pagination, error behavior, or empty result handling. 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.

  Conciseness5/5

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

  The description is extremely concise: a short purpose statement, a return example, and an auth note. Every sentence adds value, and the most important information is front-loaded. No filler or redundancy.

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

  Completeness4/5

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

  For a simple read-only tool with annotations and a single parameter, the description includes a return example and auth requirement, making it reasonably complete. It lacks comparison to sibling tools and edge-case hints, but the minimal nature of the tool and existing schema/annotations cover most needs.

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

  Parameters3/5

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

  The schema already describes gamePks as 'Game id(s).' with 100% coverage. The description implies the parameter refers to one or more games but adds no additional semantic detail such as accepted formats, limits, or specific game ID types. Baseline for high schema coverage is 3.

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

  Purpose5/5

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

  The description clearly states 'Uniforms worn in one or more games', which identifies the specific resource (uniforms) and action (retrieving for games). It also distinguishes itself from sibling mlb_team_uniforms by focusing on game-based lookup rather than team-based lookup. The return shape provides further clarity.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool versus alternatives like mlb_team_uniforms or mlb_schedule. The description only states what it does and gives an auth note, but does not mention suitable scenarios, exclusions, or related tools.

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

• mlb_player_statsA
  3.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description only needs to add context. It adds 'Auth: none needed' and specifies the return shape, which is valuable beyond the annotations. No contradictions detected.

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

  Conciseness5/5

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

  The description is two sentences: the first front-loads the core purpose and options, the second provides the return format and auth requirement. Every word earns its place; no redundancy or fluff.

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

  Completeness4/5

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

  Despite having no output schema, the description includes a return shape ({stats:[{type, group, splits...}]}), which compensates. It covers all parameter dimensions and scopes the tool to a single player, though it lacks examples or edge-case details like default season behavior.

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

  Parameters3/5

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

  Schema description coverage is 100%, so parameters are well-documented. The description adds a small connection between type/group and the return structure (splits with season/team/league), but does not substantially extend the schema's explanations.

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

  Purpose4/5

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

  The description clearly states 'One player's stats' and enumerates selectable types (season/career/yearByYear/gameLog) and groups (hitting/pitching/fielding), making its purpose specific. It distinguishes from sibling tools like mlb_player (player info) and mlb_player_game_stats (game-specific stats) by covering multiple stat types, though it lacks an explicit verb like 'get'.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives. The type and group parameters imply use cases, but no comparison to sibling tools like mlb_player_game_stats or mlb_team_stats is given, leaving the agent to infer the boundary.

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

• mlb_team_personnelA
  3.6/5.0
  Behavior4/5

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

  Annotations already mark this as read-only, idempotent, and open-world. The description adds that no auth is needed and specifies the exact return shape ({roster:[{person, job, title}], teamId}), providing useful behavioral context beyond the annotations. No contradictions.

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

  Conciseness5/5

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

  The description is very concise and front-loaded, with three short lines each serving a purpose: defining the resource, stating the return shape, and noting auth requirements. No wasted words.

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

  Completeness4/5

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

  The tool is simple (2 params, no output schema), and the description covers the essential aspects: what it returns, auth requirements, and scope. It doesn't elaborate on date behavior or field meanings, but the schema handles parameter details. Given annotations and 100% schema coverage, this is reasonably complete, though it could mention the default behavior when date is omitted.

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

  Parameters3/5

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

  Schema description coverage is 100% for both parameters (date and teamId), so the schema fully documents them. The description adds no additional parameter semantics beyond what the schema already provides.

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

  Purpose4/5

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

  The description clearly identifies the tool as providing a team's front-office/non-uniformed personnel, and the 'Returns' line confirms it's a retrieval operation. It implicitly distinguishes from sibling tool mlb_team_roster (uniformed players) by specifying 'non-uniformed personnel,' but lacks an explicit verb like 'Get' or 'List.'

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool vs alternatives like mlb_team_roster or mlb_team_coaches. The 'non-uniformed personnel' wording implies it's for front-office staff, but it doesn't state exclusions or name alternatives. Minimal usage context.

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

• nhl_game_landingA
  3.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and side-effect expectations. The description adds valuable context beyond annotations by detailing the response structure (including nested scoring and penalties arrays) and explicitly stating 'Auth: none needed', which helps the agent understand what to expect.

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

  Conciseness5/5

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

  The description is well-structured and front-loaded: first a one-line purpose, then a clear return schema, then a concrete example, then authentication note. Every sentence serves a purpose, and the formatting with bullet-like schema breaks makes it easy to scan.

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

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only one parameter and no output schema, the description compensates well by providing a detailed return object structure and an example. It is not fully complete—it does not note whether the tool works strictly for completed games or live games, nor any error conditions—but it gives sufficient context for a typical AI agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full coverage (100%) for the single required gameId parameter, describing it as an NHL game id required as part of the URL path. The description adds an example value but does not introduce semantic details beyond the schema, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a game landing page with scoring summary by period, three stars, penalties, and team game stats. It distinguishes its content scope but does not explicitly contrast it with sibling tools like nhl_boxscore, leaving some ambiguity about when to choose one over the other.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives like nhl_boxscore or nhl_scores. It gives an example call and mentions auth requirements, but does not specify prerequisites, appropriate game states (e.g., live vs completed), or when a different tool would be more suitable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_championship_driversA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  While annotations already declare readOnlyHint, idempotentHint, and openWorldHint, the description adds value by explicitly stating the return format (top-level array with fields) and noting 'Auth: none needed'. It also clarifies that data covers before/after session states, which is behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, with a clear purpose statement followed by a compact return format example. Every sentence adds value, and it is appropriately front-loaded with the main purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with only three parameters and no output schema, so the description's explicit return fields and auth note largely compensate for missing output schema. It does not cover optional parameter behavior like using 'latest', but the schema already provides that, so this is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all three parameters already have clear descriptions. The tool description does not repeat parameter details but does mention session_key in the return structure, reinforcing its role. This meets the baseline for high schema coverage with minimal additional semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides Drivers' championship standings around a race, specifically points and position before/after the session. It also lists the return structure, making the purpose unambiguous. It differentiates from sibling tools like openf1_championship_teams by mentioning 'Drivers'', though it does not explicitly name the alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'around a race' hints at context but does not explicitly state when to use this tool versus alternatives such as openf1_session_result or openf1_drivers. There is no mention of exclusions, prerequisites, or specific scenarios where this endpoint is preferred.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_broadcasting_eventsA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, open-world, and idempotent behavior. The description adds valuable context beyond these annotations by specifying the date format (ISO 8601 UTC), the auth requirement (none), and the return shape ('{pageInfo, content:[...]}'). This enhances transparency without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: the first line states the purpose, followed by return format and auth requirement. Every sentence earns its place with no redundant information. It is front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (3 optional parameters, no output schema, strong annotations), the description covers essential aspects: purpose, date format, auth, and a top-level return structure. It is slightly vague on the contents of 'match/broadcast schedule entries', but this is acceptable for a simple read-only schedule tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% description coverage for all three parameters (fromDate, toDate, pageSize). The description does not add additional parameter-level meaning, so it relies on the schema. The baseline score of 3 applies because the schema does the heavy lifting and the description offers no extra semantic detail.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as a TV/broadcast schedule for a date range, using ISO 8601 UTC. It lacks an explicit verb like 'list' or 'get', but the noun phrase is functional and distinct from siblings like 'afl_broadcast_events' or 'pl_broadcast_match_events' by virtue of the tool name and context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives. There are sibling tools like 'pl_broadcast_match_events' or 'afl_broadcast_events', but no mention of how this schedule tool differs or when to prefer it. The usage context is only implied by the name and description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_broadcast_match_eventsA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds useful context: no auth required and the return shape. However, it does not describe pagination behavior beyond the schema's pageSize default, nor the nature of 'broadcast entries.' This is adequate for a read-only tool with strong annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise, front-loaded sentences covering purpose, return type, and authentication. Every sentence earns its place with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with one required parameter and no output schema, the description provides sufficient context: purpose, key parameter, return shape, and auth. It could be enhanced by clarifying how this differs from pl_broadcasting_events, but it is not critically incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with meaningful descriptions. The description's mention of 'sportDataId = SDP match id' adds no value beyond the schema, which already states 'SDP match id (from pl_matches).' Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Broadcast events for a specific match' with a specific identifier (sportDataId). It distinguishes from likely siblings like pl_broadcasting_events by emphasizing 'specific match' rather than a general listing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied via 'specific match' and the note that sportDataId comes from pl_matches, but no explicit alternatives or exclusion criteria are provided. The agent must infer when to use this over pl_broadcasting_events or pl_match_events.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_match_officialsA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which tell the agent this is a safe read operation. The description adds 'Auth: none needed' and a return object structure ({matchId, matchOfficials: [...]}), which are useful behavioral details not covered by annotations. This exceeds the baseline while remaining concise, though it doesn't address error handling or empty results.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, consisting of a short purpose phrase, a return signature, and an auth note. It front-loads the resource name and roles, and every sentence carries useful information with no filler. This is an efficient, well-structured description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one required integer parameter, no output schema), the description provides enough context for basic usage: it names the resource, identifies the input, and gives a partial return shape. The '…' leaves some response fields unspecified, but for a straightforward read-only fetch this is sufficient. Missing details like error responses or empty behaviors are not critical for this simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers the single parameter exhaustively with 'Match id. Required — part of the URL path.' The tool description does not add any further insight about the id parameter, such as how to obtain it or any value constraints. With 100% schema coverage, the baseline of 3 applies, and the description contributes no additional semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'Match officials' and enumerates the specific roles (referee, assistants, fourth official, VAR), making it unambiguous what data is returned. The 'Returns:' line reinforces that it provides match officials for a given match. However, the description lacks an explicit verb like 'Get' or 'List', so it reads as a noun phrase rather than an action statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to select this tool over sibling tools such as pl_match, pl_match_lineups, or pl_match_stats. There are no mention of alternatives, conditions, or exclusions, so an agent has no clue about the intended use case beyond the tool's obvious resource type.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_season_teamsA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the baseline safety is clear. The description adds value by explicitly stating 'Auth: none needed' and detailing the return format ({pagination, data:[...]}) and the scoping to the season's table, which goes beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences plus a return-type line and an auth note. Every phrase is purposeful, with no filler or redundant information, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool, the description includes the return structure and auth requirement. It does not elaborate on pagination fields, but no output schema exists, so the provided return format is sufficient for an agent to understand what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with all three parameters (cid, sid, limit) described in the input schema. The description does not add meaningful parameter semantics beyond hinting at the default 20 teams, so it meets but does not exceed the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns teams for a given season, scoped to 'the 20 in that season's table.' It distinguishes from generic team tools like pl_teams (all teams) and pl_team (single team) by specifying the season context, though it lacks an explicit action verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as pl_standings or pl_teams_by_id. It implies the need for cid and sid but does not state when this is the preferred choice or any exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_teamA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only/open/idempotent, and the description supplements with return field names and an authentication note ('Auth: none needed'). No side effects or edge cases are disclosed, but for a simple read operation this adds sufficient transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a compact 3-line block: purpose, return fields, and auth. Every line is informative and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter read-only getter, the description provides purpose, return shape, and auth. It lacks explicit differentiation from pl_teams_by_id and does not describe the shape of player_id (e.g., whether it's an array), but overall covers essential invocation context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with descriptions and examples (cid, tid, including team ID examples). The description adds no additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states 'One team within a competition by id' and lists returned fields, clearly indicating a read operation for a single team. It distinguishes from plural listing tools like pl_teams, but doesn't explicitly differentiate from sibling pl_teams_by_id.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use guidance or alternatives are mentioned. The phrase 'within a competition' implies the need for both cid and tid, but no exclusions or comparisons with similar team retrieval tools are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_team_formA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, covering safety and mutability. The description adds 'Auth: none needed' and a return shape, which are useful beyond the annotations. It does not disclose potential response size limits or edge cases, but given the strong annotation coverage, this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two lines of summary plus a return type and auth note. It is front-loaded with the primary purpose and includes only essential supplementary details, with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with full schema descriptions and safety annotations, the description provides sufficient context. It omits a precise definition of 'recent' or how many matches are returned, but the tool is low complexity and the output structure is clarified, making it adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% parameter descriptions, including values like 'Competition id (8)' and 'Season id (2025 = 2025/26)'. The description adds no parameter-specific details beyond the schema, so it does not enhance understanding; baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly indicates the tool returns one team's recent matches/form within a season, listing the exact output fields. It distinguishes from most siblings by specifying 'within a season' and the return structure, but does not explicitly contrast with the similarly named pl_teamform, leaving slight ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No information on when to use this tool vs alternatives. Siblings like pl_teamform or pl_team_stats are not mentioned, and there is no guidance on selecting this over them. The only implicit hint is 'recent matches/form,' but it lacks explicit context or exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_video_popularA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds the return shape (array of {title, canonicalUrl, date}) and explicitly states no authentication is needed, both of which are behavioral details not present in 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, consisting of only the summary, the return format, and an auth note. Each segment provides distinct value with no redundancy or filler, making it well-structured and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with two optional parameters, the annotations cover read-only/idempotent behavior, the schema documents the parameters, and the description provides the return format and auth requirement. However, it does not elaborate on the ordering or the precise meaning of 'popular', nor explicitly state that an array is returned (though the return format implies it). Overall, it is nearly complete for a filtered list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for both parameters (limit as page size, recency as lookback window), achieving 100% coverage. The description reinforces recency by referencing it in the summary, but adds minimal additional meaning beyond the schema, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Popular video over the last `recency` hours' and provides the return format, making it clear the tool returns popular videos within a time window. However, it lacks an explicit verb like 'list' or 'get', and while it is distinguishable from sibling tools like pl_video_latest by name, the description does not explicitly contrast it with alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool versus alternatives such as pl_video_latest or pl_news_popular. The only contextual hint is the recency window, which implies a use case for recent popular videos, but there are no exclusions or alternative tool references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_promotionsA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and open-world behavior. The description adds that no auth is needed and provides a sample return shape, which is useful but not extensive. It doesn't contradict annotations and adds modest value beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise lines cover purpose, return format, and auth requirement. No wasted words, and each sentence carries distinct information. The trailing '...' and 'etc.' are minor but acceptable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two optional params, the description covers the core aspects: what it returns, where it's used, a sample return structure, and auth requirements. Without an output schema, the return hint helps, and the annotations fill in safety guarantees. Slight lack of detail on pagination or filtering, but not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers both parameters with descriptions, giving 100% schema description coverage. The tool description does not add any extra parameter-level context, so it relies fully on the schema, which meets the baseline but adds no bonus value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns 'Live promotions for a display surface (carousel, etc.)', identifying both the resource (promotions) and the specific use case. It doesn't explicitly differentiate from siblings like pointsbet_promo_code, but the display-surface scope provides a distinct purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for a display surface' implies usage context (e.g., carousels), but there is no explicit comparison or exclusion of alternatives like pointsbet_promo_code or sportsbet_popular_promotions. It has implied context but no direct guidance on when to choose this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_racing_featuredA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  While annotations already declare read-only/idempotent behavior, the description adds that no authentication is needed and specifies the return structure, which provides useful operational context. No contradictions detected.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, using three short sections for purpose, return shape, and auth requirement. Every sentence adds value and the structure is clear with labeled return and auth fields.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool, the description is fairly complete, including an inline return schema and auth status. However, it does not clarify what 'codes' means or what criteria define 'featured,' which could cause slight ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both raceCount and runnerCount fully documented in the input schema. The tool description does not add any additional parameter semantics, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns featured races with top runner previews, providing a specific resource and scope. The word 'featured' distinguishes it from general race-listing tools like pointsbet_racing_races, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide any guidance on when to use this tool versus other racing tools. It lacks any exclusions, prerequisites, or alternative recommendations, leaving the agent to infer usage solely from the name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_sport_competitionsA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description supplements the read-only/idempotent annotations with the return shape, the grouping by locale, and explicit note that no auth is needed. It does not elaborate on potential edge cases, but the annotations already cover safety, and the added context is useful.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured; it starts with purpose, gives the return schema, includes a concrete example, and ends with auth. No unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description explicitly defines the return structure and provides an example, covering the essential context for a simple read-only list tool. Minor gaps remain around locale semantics, but overall it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The sole parameter sportKey is fully described in the schema with examples, so the description adds little beyond a concrete AFL example. Schema coverage is 100%, making this an adequate baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as competitions for a specific sport, grouped by locale, and includes a return structure example. It distinguishes itself from sibling tools that handle events or feature sliders, though it does not explicitly contrast alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool compared to alternatives like pointsbet_competition_events or pointsbet_sport_featured_events. The provided example shows a valid invocation but does not state the intended use case or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_sports_inplayA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, establishing the safety profile. The description adds authentication requirements and the return structure, but does not disclose any potential caveats or edge cases (e.g., whether only sports with active events are included). It adds some value beyond annotations but not rich behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, with one sentence for the core purpose, one line for the return structure, and one for auth. No wasted words; every element adds value and is front-loaded with the most important information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple zero-parameter read-only tool, the description is fully complete. It explains the return structure (which is standard practice since no output schema exists), specifies that no auth is needed, and clearly states the data scope. No further information is necessary for the agent to select and invoke this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description does not need to explain parameter semantics. The schema coverage is 100% vacuously, and the baseline for 0 params is 4, which is appropriate here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (sports currently in-play) and the key output (live event count per sport). It distinguishes from siblings like pointsbet_sports_list and pointsbet_inplay_streaming through its focus on in-play status and event counts, though the verb 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.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention alternative tools, exclusions, or situational context beyond the core purpose, leaving the agent to infer usage from the tool's name and output.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• seriea_standingsA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context: no auth required, exact return structure (three tables, team fields, stats keys), and an example seasonId. It does not contradict annotations and provides value beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is well-structured and front-loaded with the main purpose, followed by return schema and example. It is slightly verbose but every sentence adds value (structure, stats explanation, auth). No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only standings tool with no output schema, the description thoroughly explains the response format, stats semantics, example seasonId, and auth. It is complete enough for an agent to invoke and interpret results correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds a concrete example seasonId value, which helps illustrate the format, but does not explain the locale parameter beyond the schema's 'Label language.' Minimal added meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns a league table for a season, with specific structure (three tables: overall, home, away). It is distinct from siblings by describing the three-table organization, but does not explicitly name alternative tools for other standings/league information.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use guidance or mention of alternatives. It only provides an example seasonId and notes auth is not needed. Does not clarify how this differs from related tools like seriea_team_stats or pl_standings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sleeper_matchupsA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, idempotent, and open-world behavior. The description adds meaningful context: the relationship between rosters sharing a matchup_id (no home/away), the return structure, and auth requirements, which goes 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is mostly well-structured with return format, example, and auth, but the final 'Also answers this' line is vague and detracts from focus; it does not clearly earn its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only data retrieval, the description provides sufficient detail: return format, an example, auth note, and matchup semantics. The ambiguous ESPN cross-reference is the only weakness, but overall it is complete enough for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear descriptions for both week and league_id. The description's example reinforces usage but does not add new semantic detail beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns one week's matchups with roster points, starters, and per-player scoring. It is specific about the resource and content, though it lacks a direct verb form and the trailing cross-reference to ESPN tools adds ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use for Sleeper league matchups and provides an example, but it does not explicitly state when to prefer this over alternatives. The 'Also answers this' line hints at covering similar ESPN tools but is ambiguous and does not give clear exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_bet_liveA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds 'Auth: none needed' and a return format specification, which are useful beyond the annotations. The annotations already cover readOnlyHint, openWorldHint, and idempotentHint, so additional behavioral context is minimal but present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise lines: purpose, return format, and auth. It front-loads the primary purpose and avoids any redundant or verbose content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Provides purpose, return structure, and auth requirements. With 100% schema coverage and readOnly annotations, the description is sufficiently complete for a simple feed tool, though it omits optional details like pagination or data freshness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions fully cover all three parameters with clear explanations. The tool description does not add extra parameter semantics, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns a 'BetLive feed — events currently in-play and bettable live' and specifies the return shape. This distinguishes it from other sportsbet tools focused on markets or racecards, though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or when-not-to-use guidance, but 'currently in-play and bettable live' implies the intended use case. It lacks exclusions or alternative tool references, so it falls at the 'implied usage' level.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_race_previewA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and open-world behavior. The description adds that auth is not needed and specifies the return object shape, which is extra context. However, it doesn't disclose error behavior, null cases, or other limitations, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences: purpose, return structure, and auth. It is front-loaded with the primary purpose, contained no fluff, and every line adds needed information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool, the description covers the purpose, return format, and auth. Combined with complete schema descriptions and annotations, it is nearly complete. It lacks any mention of when the preview might be unavailable, but that is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with all four parameters (raceType, trackName, raceNumber, eventDate) already described. The description adds no additional parameter-level meaning, so it earns the baseline score for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides an 'Editorial race preview (text + video) for one race,' with a specific resource and scope. It distinguishes itself from sibling tools like racecards or form by specifying 'editorial' and 'text + video.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool vs. alternatives like sportsbet_racecard or sportsbet_match_preview. It does not mention any exclusions or fallback tools, leaving the agent without decision support.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_results_classesA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, open-world, and idempotent behavior. The description adds the return format, an example, and an auth note, which are useful but do not go beyond what the annotations and schema already imply. It does not mention edge cases like empty results or error handling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: opening purpose, return format, example, and auth note. Every sentence adds value without redundancy. It is front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, no output schema), the description is complete enough: it specifies the return structure, provides an example, and notes auth. It covers the essential context for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single 'date' parameter. The description reinforces the parameter semantics with the example using 'today', but does not add substantially new information beyond the schema description, which already documents YYYY-MM-DD or 'today'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states that this tool returns sport classes with results for a date, and includes the return structure ({classes:[{classId, name}]}). This clearly distinguishes it from sibling tools like sportsbet_results_competitions (which focuses on competitions), though it lacks an explicit verb like 'retrieves' or 'lists'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for finding classes with results on a given date, and provides an example with 'today'. However, it does not explicitly state when to use this tool over alternatives, nor mention any exclusions. The context is clear but the guidance is only implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_sport_card_legacyA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable context by explicitly stating 'Auth: none needed' and outlining the return shape. This goes beyond what annotations provide and helps set expectations for the response format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, using just two short sentences plus a small code block for the return structure. Every element earns its place: the resource type, the payload shape, and the auth requirement. No filler or redundant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with one well-documented parameter and strong annotations, the description is nearly complete. It provides the return structure, which substitutes for an output schema, and confirms no authentication is needed. The main gap is the vague term 'primary markets' and the lack of clarification on whether 'legacy' implies deprecation or behavioral differences.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for the single 'eventId' parameter, including a description that it is required and part of the URL path. The tool description reinforces the use of eventId in the return object but does not add any new parameter-specific details beyond what the schema already states. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies the resource as a 'Legacy single sport event card' that returns an event and primary markets. While it lacks an explicit verb like 'get' or 'fetch', the return structure '{event:{...}, markets:[]}' clearly indicates a retrieval operation. The word 'Legacy' and 'single' help distinguish it from plural card endpoints in the sibling list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool over alternatives. The word 'Legacy' hints that a newer version may exist, but no alternative tool is named, and no conditions or exclusion criteria are stated. The description does not explain scenarios where this endpoint is preferred.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_sport_resulted_eventsA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by specifying the exact return structure '{events:[{eventId, name, finalScore}]}' and explicitly stating 'Auth: none needed,' providing useful behavioral context beyond what the annotations convey. No contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three compact lines covering purpose, return format, and authentication. It is front-loaded, with no redundant or wasteful sentences, and every line earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity—three well-documented parameters, strong annotations, and no output schema—the description provides sufficient coverage of purpose, return shape, and auth. It lacks explicit usage guidance or pagination details, but these are minor gaps for a straightforward read-only lookup.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already described (e.g., date 'Result date, YYYY-MM-DD.' and competitionId 'Required — part of the URL path.'). The description does not add additional parameter-level detail, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Resulted (finished) events for a sport competition + class + date.' This is a specific verb+resource+scope that leaves no ambiguity about what the tool does. However, it does not explicitly differentiate from sibling tools like sportsbet_event_results, though the scope is sufficiently distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. It neither mentions exclusions nor suggests alternative tools for other use cases. The description only defines the tool's purpose, leaving the agent to infer usage context without any comparison to siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_racing_futures_meetingsA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as readOnly, openWorld, and idempotent, so the description need not restate those. It adds value by disclosing the exact return shape and the authentication behavior ('works without a key; TAB_CLIENT_ID or TAB_CLIENT_SECRET unlocks more if set'), which goes beyond structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short, information-dense parts: a clear definition, the return shape, and authentication requirements. Every sentence earns its place with no filler or repetition of schema/annotation content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description provides a useful return structure and explains the auth context. Optional parameters are covered by schema descriptions. It is slightly under-specified on how jurisdiction or promo flags affect the response, but overall it is adequate for a simple optional-parameter list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter (returnPromo, jurisdiction, returnOffers) has a description in the input schema. The main description adds no additional parameter-level meaning, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'futures racing meetings' and adds clarifying context with 'ante-post / long-dated markets like Cup outrights', distinguishing it from regular racing meetings among siblings. It lacks an explicit verb phrase like 'list' or 'retrieve', but the 'Returns:' line makes the tool's behavior unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives such as tab_racing_meetings or tab_racing_futures_race. The parenthetical definition implies use for long-dated/ante-post markets, but there are no stated exclusions or alternative tool references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_liking_usersA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only and idempotent behavior; the description adds valuable context by specifying the return shape ({data:[{id, username, name}], meta:{result_count}}) and the authentication requirement (X_BEARER_TOKEN). This goes beyond annotation information.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded. The first sentence states the purpose, followed by concise return format and auth. Every sentence contributes value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with full schema coverage, the description adequately covers purpose, return structure, and auth. It lacks usage alternatives or pagination behavior details, but these are not critical given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% parameter descriptions, including id being part of the URL path and max_results constraints. The description adds no additional parameter details, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies the resource as 'Users who liked a given post' and implies the action of retrieving them. It is distinct from sibling tools like twitter_retweeted_by or twitter_quote_tweets, though it lacks an explicit verb like 'get' or 'list'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention sibling tools or exclusion criteria, leaving the agent without context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_my_teamsA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint, openWorldHint, and idempotentHint, which already indicate a safe read operation. The description adds critical context: return shape is unverified from vendor docs and may be approximate, plus notes the awkward nested structure. It also mentions auth requirements. This goes beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is informative and structured: it starts with purpose and key value (team_key), includes return shape, notes unverified shape, gives example, and auth info. Some redundancy but each part adds value. Not overly verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description provides return shape (unverified), example, auth note, and warns about nested structure. No output schema exists, so this compensates well. It could mention potential errors or limits, but given the tool's simplicity and good annotation coverage, it's fairly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers both parameters with 100% coverage: gameKeys is described as required comma-separated, format is 'Leave as json.' The description adds an example ('gameKeys': 'nfl') which helps but doesn't significantly exceed schema. Schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool provides the authenticated user's own fantasy teams, and highlights that it returns team_key needed for writes. This is clear and distinguishes it from sibling tools like yahoo_my_games and yahoo_my_leagues, though it doesn't explicitly name a sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: it's for getting the user's teams and especially useful for obtaining team_key before writes. It does not explicitly state when not to use it, but the example and focus on team_key guide usage. It lacks explicit alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_teamA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint and idempotentHint annotations, the description adds important behavioral context: it requires explicit authentication keys (noting the environment variables) and warns that the response shape is based on vendor documentation and has not been verified against a live response, advising users to inspect the actual payload. This goes beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections (general description, return shape, notes, example, auth). It is not overly verbose, though it includes a detailed return shape that could be considered lengthy, but it's necessary given the absence of an output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description provides the expected return shape, notes the uncertainty (vendor docs vs. verified), includes an example, and covers authentication. It lacks detailed explanations of each field's meaning, but that's acceptable given the scope. Overall, it offers sufficient context for a developer to use the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for both parameters (format and teamKey). The description adds an example of teamKey's format, reinforcing the schema's description. Since schema coverage is 100%, the baseline is 3, but the example adds a bit more clarity, warranting a 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool returns metadata for a single team, listing the specific fields (name, manager, waiver priority, etc.). This distinguishes it from other yahoo_team_* tools (like roster or stats) by focusing on metadata, though it doesn't explicitly contrast with them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide guidance on when to use this tool versus other team-related tools (e.g., yahoo_team_roster, yahoo_team_stats). It only describes what it returns without contextualizing its use case or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_broadcast_eventsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds useful behavioral context beyond the annotations: it specifies the return shape ('{pageInfo, content:[...]}'), states 'Auth: none needed', and clarifies the data granularity ('one entry per match per channel'). The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description does not contradict them. The main gap is a lack of mention of pagination behavior or filtering semantics, but the provided details are sufficient to earn a 4.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, with four short, informative sentences. It front-loads the core purpose ('Broadcast schedule') and then provides return format, auth, and alternative tool mentions. The 'Also answers this' line is somewhat cryptic but not verbose. Every sentence earns its place, though the phrasing could be clearer, preventing a perfect score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a listing tool with 5 parameters and no output schema, the description provides a good amount of context: purpose, return shape, auth, and alternative tool mapping. The annotations cover read-only/idempotent behavior, reducing the burden. However, it lacks explanation of how parameters like round/date range interact, how pagination works (pageSize), or when to use this vs. afl_broadcast_event_get. These gaps prevent a 5, but it is reasonably complete for an agent to make an initial selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 does not add any extra meaning about parameters; it only mentions the return format and general scope. Since every parameter already has a clear schema description (round, toDate, fromDate, pageSize, compseason), the tool description compensates adequately without needing additional parameter explanation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Broadcast schedule' which clearly identifies this as a listing tool for broadcast events, and the phrase 'one entry per match per channel' adds specific scope. It distinguishes from sibling tools like afl_broadcast_event_get by implying a collection endpoint vs. a single event. However, it lacks an explicit verb like 'list' or 'get', making it slightly less direct than the ideal.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The line 'Also answers this: espn_core_call, pl_broadcasting_events, pl_broadcast_match_events' provides some alternative tool guidance, hinting that this tool can serve the same purpose as those. However, it does not clearly state when to prefer this tool over others, nor does it mention exclusions like using afl_broadcast_event_get for a single event. The guidance is cryptic and lacks explicit when-to-use vs. when-not-to-use framing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_live_audioA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses important behaviors beyond the annotations: empty when no game is live, return structure with pageInfo and content containing id/name/channels, and no auth needed. This complements the readOnlyHint/idempotentHint annotations without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the primary purpose, followed by return format and auth. It avoids unnecessary detail, though the 'Also answers this: openf1_team_radio' line is an odd addition that somewhat disrupts the clean structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool, the description provides essential context: live-only availability, empty result condition, return shape, and auth requirements. It doesn't explain the channels array contents, but the schema and return structure make it largely self-explanatory.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all three parameters (round, pageSize, compseason) with 100% description coverage, so the baseline of 3 applies. The tool description itself adds no additional parameter semantics beyond what's already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as providing live AFL audio streams and notes that it returns empty when no game is live. This distinguishes it from siblings like afl_live_video (video vs audio), though it lacks an explicit verb and the 'Also answers this: openf1_team_radio' note adds a confusing cross-domain capability.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: it's for live AFL audio, with the caveat that it's empty when no game is live. However, there is no explicit 'when to use vs alternatives' guidance, and the note about openf1_team_radio is a routing hint rather than a clear usage policy.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_mma_fightsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint and idempotentHint annotations, the description discloses valuable behavioral traits: the winner field being null until resulted, both fighters possibly false on a draw/no-contest, and the unverified nature of the return shape from vendor docs. It also clearly states the auth key requirement, adding practical context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with labeled sections (Returns, NOTE, Example, Auth) and includes only relevant caveats. It is not overly verbose, though the example card is minimal and could be slightly more illustrative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description compensates by providing the return shape and important caveats about its reliability. It also mentions auth. However, it does not address potential interactions between the four optional parameters or pagination/limitations, so it is not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter is already well-documented. The description adds only a minimal usage example (date string) but no deeper parameter semantics or nuances, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as retrieving MMA fights (UFC and others) by date or season, which is specific enough. However, it lacks an explicit action verb (e.g., 'list' or 'get'), and it does not explicitly distinguish from sibling tools, though the MMA resource is unique among siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use for MMA fight queries when filtering by date or season, but it does not mention alternatives or when-not-to-use scenarios. It also does not explain how multiple parameters interact (e.g., whether id and date can be combined). The auth requirement is mentioned, but that is a prerequisite, not a usage guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apitennis_standingsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds valuable context by disclosing the unverified return shape and the need for a personal API key, which goes beyond annotations. This extra transparency is useful for the agent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with line breaks separating the summary, return shape, caveat, example, and auth note. Each section earns its place, though the unverified-shape note is a bit verbose. It is concise enough for the complexity involved.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of an output schema, the description compensates by providing the expected return shape and a clear caveat. Annotations cover safety and idempotency, and the schema covers parameters completely. The only gap is explicit alternative guidance, but for a simple rankings tool the description is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters documented ('Leave as-is' and 'Tour. One of: ATP, WTA'). The description adds an example showing exact usage, but this is redundant with the schema. No additional parameter semantics (e.g., formats, behavior) are provided, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'ATP or WTA rankings,' which clearly identifies the resource and scope. It distinguishes from other sports' standings tools, though it does not explicitly differentiate from the sibling wta_rankings tool. The absence of an explicit verb (e.g., 'Get') is minor since 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an example call and auth requirement, which gives practical usage context. However, it does not explicitly state when to use this tool versus alternatives (e.g., wta_rankings or other standings tools). Usage is implied by the ATP/WTA scope but lacks explicit exclusions or alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• balldontlie_nba_playersA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that the response shape is from vendor docs and unverified, advises inspecting the actual payload, and notes that a personal API key (BALLDONTLIE_API_KEY) is required. These details go beyond the readOnly/openWorld/idempotent annotations, providing important reliability and authentication context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: purpose, return shape, caveat, example, auth. Each section earns its place with no filler. The only minor issue is the inclusion of a detailed return shape, which is useful but somewhat lengthy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple search/resource tool with no output schema, the description provides the approximate return shape, pagination fields, an example, auth requirements, and a verification caveat. While it could mention error handling or rate limits, the provided details are sufficient for the tool's apparent complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 parameters (cursor, search, per_page, team_ids). The description adds a concrete usage example ({"search": "curry"}) but doesn't explain parameter semantics beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'NBA players, searchable by name' clearly identifies the tool as providing NBA player data, distinguishing it from sibling balldontlie tools for teams, games, stats, etc. The example 'Search a player' implies an action, even though there's no explicit verb like 'list' or 'get'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving NBA player data by name, but does not explicitly contrast with alternatives like balldontlie_nba_teams or other siblings. There's no 'use this when' or 'instead of' guidance, leaving the agent to infer from context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• balldontlie_nba_season_averagesA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds critical behavioral caveats: the response shape is from vendor docs and unverified, the payload should be inspected before trusting field names, and authentication requires a personal BALLDONTLIE_API_KEY. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is multi-paragraph but every section earns its place: purpose, return shape, critical unverified-shape note, example, and auth requirement. It is front-loaded with the primary function and avoids fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides an approximate return shape, an example input, and auth info, making it adequately complete for a read-only stats endpoint. The explicit caveat that the shape is unverified appropriately manages expectations given the lack of live verification.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both parameters described. The description provides a concrete example ('season': 2023, 'player_ids': ['115']) and reiterates the specificity of player_ids, but does not add substantive semantic detail beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns season averages for specific NBA players, which differentiates it from sibling tools like balldontlie_nba_teams or balldontlie_nba_games. The lack of an explicit verb (e.g., 'Get') is minor since the noun phrase strongly implies a retrieval operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for targeted player queries via 'specific NBA players,' and the schema reinforces this by stating the endpoint 'will not return a whole league.' However, no explicit alternatives or when-not-to-use guidance is provided, leaving the agent to infer context from the tool name and sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• balldontlie_nba_standingsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the requirement of a BALLDONTLIE_API_KEY and warns that the return shape is unverified from vendor docs, providing useful operational context beyond what annotations supply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is structured with sections (Returns, Note, Example, Auth) and contains only relevant details. It is slightly verbose due to the return shape block, but each part adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only tool with good annotations, the description covers the return shape (though unverified), an example, and auth. It lacks detail on supported seasons and exact field semantics, but is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes season as 'Season start year' (100% coverage). The description adds an example with season=2023 but no additional semantic detail such as supported year ranges or format.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'NBA standings for a season,' clearly identifying the resource (NBA standings) and the scope (season-based). It does not use an explicit verb like 'get' or 'retrieve,' and it does not differentiate from other standings tools among siblings, so it's clear but not fully distinguishing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when standings for an NBA season are needed, with an example showing season=2023. However, it provides no guidance on when to choose this balldontlie tool over other standings tools like apisports_basketball_standings or nba_standings, and no exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_master_categoryA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful context beyond annotations: it explicitly states 'Auth: none needed' and provides the exact return shape. It does not contradict annotations and covers the key behavioral aspects relevant for safe invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: a one-line purpose, a Returns block, and a brief example. Every sentence adds value, no redundancy, and the structure is easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the lack of an output schema, the Returns block fully documents the nested response structure, and the example clarifies usage. Combined with complete parameter schemas and annotations, the description provides everything an agent needs to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter is already documented. The description adds a concrete example using EventTypeId 107 and mentions 'optionally with levelled markets', but does not add significant semantics for EventClassCode or WithLevelledMarkets beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides master categories for an event type, optionally with levelled markets, and includes a return structure. It is clear but does not use a specific verb like 'get' or 'list' and does not explicitly differentiate from closely related siblings such as betr_master_event or betr_sports_category.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool versus alternatives. The example shows a valid parameter (EventTypeId 107) but does not provide context such as 'use this for top-level categories' or 'prefer this over betr_sports_category when...'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_pop_sgm_categoryA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context beyond these: 'Auth: none needed' and the exact return structure. No contradiction with annotations. This is good transparency for a simple read-only list.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: one line for purpose, one for return shape, one for auth. Every sentence adds necessary information without redundancy. Well-structured and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list tool, the description covers the essential aspects: what it returns and auth requirements. The output structure is embedded in the description. It lacks usage context, but that dimension is already scored separately. Overall adequate for a simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema provides no meaningful semantics. Baseline is 4. The description goes beyond the schema by specifying the return object shape, which helps the agent understand what to expect.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource: categories that currently have Popular Same Game Multis. It names a specific scope ('currently have Popular Same Game Multis') which distinguishes it from generic category tools, but it lacks an explicit verb like 'list' or 'get', so it's slightly less clear than it could be.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. It doesn't mention related tools like betr_pop_sgm_bet_data or betr_master_category, nor does it provide any decision context. Given the large sibling list, this gap is significant.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_statwars_eventsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds value beyond these by stating 'Auth: none needed' and explicitly listing the return structure with field names. This provides useful behavioral context about what data will be returned and confirms no authentication is required.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: one line identifying the resource, one line for the return format, and one line for auth. Every sentence earns its place, with no redundancy or unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter read operation with no output schema, the description provides the essential return structure and auth requirement, making it adequately complete. It does not explain the broader context of when one would need Statwars master events, but that is not critical for a simple list endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema carries no parameter details. Per the baseline for 0-param tools, the description need not compensate for schema gaps. It correctly does not invent parameter-related information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'Statwars master events' and adds the clarifying parenthetical 'head-to-head stats promo events', which differentiates it from generic master event tools like betr_master_event. However, it lacks an explicit action verb like 'List' or 'Get', relying on a noun phrase that implies retrieval.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool vs alternatives. It does not mention any exclusions, prerequisites, or context for selection. The only extra statement is 'Auth: none needed', which is an auth detail rather than a usage guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfbd_advanced_box_scoreA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so those are covered. The description adds valuable transparency by disclosing that the return shape is 'from vendor docs' and 'NOT been verified against a live response,' as well as the auth requirement and PPA definition. This helps the agent set expectations and inspect the actual payload.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a clear one-sentence summary, followed by the return shape, caveat, example, and auth note. Each section serves a purpose and the structure is logical, though the caveat note is somewhat verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description details the return structure and warns it is unverified. It also covers authentication and provides an example. This is a reasonably complete picture for a single-parameter tool, though it doesn't discuss error modes or edge cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and already explains that 'id' is a query parameter from cfbd_games. The description reinforces this with an example value, but it doesn't add significant new semantic information beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Advanced box score for one game' and lists the key metrics (success rate, explosiveness, PPA, field position), which identifies the tool's purpose and scope. It doesn't explicitly differentiate from sibling CFBD tools, but the 'one game' constraint distinguishes it from list-style tools like cfbd_games.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage via 'one game' and provides an example call, but it doesn't explicitly state when to choose this over alternatives or where to obtain the required game ID. The schema description covers the ID source, yet the tool description itself lacks that contextual guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfbd_gamesA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint), the description discloses the return shape, notes that it is unverified from vendor docs, and mentions the required API key. This adds meaningful context about expected output and operational constraints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear opening, return shape, caveat note, example, and auth requirement. It is slightly longer than necessary due to the example, but all sections serve a purpose and it is front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with no output schema, the description provides a return shape, required parameter, auth note, and a critical caveat about unverified data. The schema fills in parameter details, making the overall context adequate for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for all parameters (100% coverage), so the bar is at baseline. The description only adds an example with `year` and `week`, which does not introduce new semantic meaning beyond the schema's existing parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'Games for a season with scores, venue and attendance,' which distinguishes it from sibling CFBD tools like cfbd_teams and cfbd_rankings. It lacks an explicit verb like 'list' or 'get,' but the resource and focus are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states that `year` is required and provides an example with `week`, implying when to use it for season-specific game data. However, it does not explicitly mention alternatives or when not to use this tool, nor does it reference sibling tools for comparison.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketdata_playersA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the need for an API key and an honest caveat that the return shape is unverified from vendor docs, which is useful context. It does not contradict 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is reasonably concise and well-structured, with the main purpose front-loaded. The return shape, example, and auth note are all relevant, though the formatting could be tightened slightly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only search tool with two optional parameters and no output schema, the description provides an approximate return shape, an example, and auth requirements. It omits details about behavior when search is omitted and does not explain offset/pagination beyond the schema, but the provided information is fairly complete for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema describes both parameters (offset and search) with 100% coverage, so the baseline is 3. The description adds an example using 'search' but does not materially expand on the schema's parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Search the player catalogue by name,' which identifies a specific verb and resource. It does not explicitly distinguish this from sibling tools like cricketdata_player_info, but the search-by-name framing is clear enough for basic differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides the core purpose and an example, implying that this tool is used when searching for players by name. However, it offers no explicit guidance on when to use this tool versus alternatives such as cricketdata_player_info, and no exclusions or prerequisites beyond the auth requirement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entain_quicklinks_listA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, and the description adds useful context beyond these: the return format and the statement 'Auth: none needed.' It does not contradict annotations and provides enough behavioral transparency for a simple read-only list operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a short purpose line, a return format line, a usage example, and an auth note. Every sentence contributes useful information without unnecessary elaboration, though it could be tightened syntactically.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter list tool with no output schema, the description provides the return structure, an example invocation, and auth requirements. It does not enumerate all possible filter types (e.g., Sports), but combined with the schema this is sufficient for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the only parameter 'filter' is already described with an example and a warning about bare strings. The description repeats this example but does not add additional parameter semantics beyond the schema, maintaining the baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'Navigation quick-links (racing/sports nav tiles)' and implies a list operation through the name and return structure. It lacks an explicit verb like 'List' or 'Fetch' and does not distinguish from similar sibling tools such as 'fanduel_racing_quicklinks', but the domain and resource are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete example filter for Racing and notes that authentication is not required. However, it does not explain when to use this tool over other navigation/resource tools, enumerate possible filter types, or mention alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entain_video_channelsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds genuinely useful behavioral context beyond the annotations: HLS .m3u8 URL format, short-lived token requiring verification, no auth needed, and the 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tight and front-loaded: the first sentence delivers the core purpose and format, followed by a compact return-shape line and an auth line. Every sentence earns its place with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter, no-output-schema tool, the description is nearly complete: it provides the return structure, the URL format, the critical token-expiry caveat, and auth status. The only minor gap is that it doesn't describe any filtering or scoping options, but with zero params that's not a significant omission.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters and 100% schema coverage, so the baseline is 4 per the rubric. The description appropriately focuses on return semantics (channel id, name, url) instead of parameters, which is all that's needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this tool returns racing live-video channels in HLS .m3u8 format, with an explicit return shape of {channels:[{id, name, url}]}. The 'Racing' qualifier distinguishes it from other live-video tools like afl_live_video, though it doesn't explicitly name alternative tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus the many sibling video/broadcast tools (e.g., afl_live_video, betfair_scores_broadcast, pointsbet_inplay_streaming). The token-expiry warning is an operational caveat but does not help with tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fanduel_racing_promotionsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations (readOnlyHint=true, idempotentHint=true, openWorldHint=true) already establish the safety profile. The description adds meaningful behavior: it specifies the HTTP method (POST), the auth requirement, and the response shape. This goes beyond annotations, but it stops short of describing pagination or data details, so a 4 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: three short segments covering purpose, response, and auth. Every sentence is informative and there is no repetition of structured data, making it a 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description gives the top-level response structure and auth info, but with no output schema, the nested promoPlacements object structure is left as ellipses. The body allows additional properties but no filter guidance is provided. For a simple default call, it's adequate but leaves some gaps, so a 3.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides a full description of the 'body' parameter with 'Optional filter body; {} returns the default placements', giving 100% model coverage. The description's 'empty body returns all' adds a slight clarification but does not substantially enrich the parameter semantics. Baseline for high schema coverage is 3, and no compelling extra context is provided, so a 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning structured racing promotions and placements, with 'empty body returns all' specifying the scope. However, it lacks an explicit verb like 'list' or 'get' and does not distinguish itself from sibling FanDuel racing tools beyond the resource name, so it earns a 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides usage context by stating that a POST with an empty body returns all placements and that no auth is needed, but it does not explicitly state when to choose this tool over alternatives or any exclusions. The usage is implied by the tool name and description, so this is a 3.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• footballdataorg_teamsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the authentication requirement (403 without key) and explicitly warns that the return shape is from vendor docs and unverified, which adds valuable context beyond the annotations. Annotations already declare readOnly, openWorld, and idempotent hints, and the description does not contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is organized into clear sections (purpose, return shape, note, example, auth) and front-loads the purpose. The return shape block is lengthy but necessary given the absence of an output schema; overall it avoids unnecessary prose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the key invocation details: required competition, optional season, authentication, and a caveat about response shape. It lacks alternative tool guidance but is otherwise sufficient for a read-only listing operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both parameters. The description adds an example value ('PL') and mentions the competition is part of the URL path, reinforcing the schema but not significantly extending it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'The clubs in a competition' and includes a return shape, making it clear this tool lists teams for a specified competition. It is distinguishable from sibling tools like footballdataorg_team (single team) and footballdataorg_competition (competition details), though it lacks an explicit action verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by providing an example with 'competition': 'PL' and emphasizes the need for an API key, but it does not state when to prefer this over alternatives such as footballdataorg_standings or pl_teams. There are no explicit exclusions or alternative recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• golfcourseapi_courseA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint, openWorldHint, and idempotentHint, so the core safety profile is covered. The description adds substantial value by disclosing the unverified nature of the response shape, explaining the male/female tee split, and clarifying that 'handicap' means stroke index, not a player handicap. This goes beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is fairly long but well-structured with a purpose statement, return shape, caveats, example, and auth note. Every part contributes meaningful information, though the 'Example: One course in full' section is slightly redundant and could be trimmed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a detailed return shape including the nested structure and field meanings. It also includes a reliability caveat and auth requirement. The description is reasonably complete for a single-course detail endpoint, though location subfields are left as '…' and error behavior is not mentioned.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema already explains that 'id' is required and comes from golfcourseapi_search. The description adds only a trivial example ({"id": 1}) without new semantic insight into the parameter, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource: a single course with full tee box details including per-hole par, yardage, and stroke index. The phrase 'One course in full' distinguishes it from the sibling golfcourseapi_search, though it lacks an explicit verb like 'Get' or 'Retrieve'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied rather than stated: the description indicates this returns full details for one course, so an agent can infer it should be used after obtaining a course ID (likely from golfcourseapi_search). However, no explicit guidance is given about when to prefer this tool over alternatives or when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• highlightly_baseball_highlightsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, lowering the bar. The description adds substantial context: the return shape is from vendor docs and unverified (advising caution), and it discloses the auth requirement (HIGHLIGHTLY_API_KEY). This goes beyond annotations and helps the agent handle potential schema drift.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is relatively brief and includes the return shape, a caveat, an example, and auth info. It is not highly structured (free-form text) but every sentence earns its place. Slightly disjointed, yet efficient overall.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a return shape, pagination field, a concrete example, and auth note. It also compensates for uncertainty with the unverified shape warning. It doesn't explain the nested match object in detail, but the approximation warning mitigates that. Fairly complete for a simple read-only tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with each parameter having a short description (date format, page size, filter by match/league). The description adds a usage example but no deeper parameter semantics, such as how multiple filters interact or default behavior. Baseline 3 is appropriate given high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'Baseball highlight clips' and the return shape confirms a retrieval function. It distinguishes from sibling tools like soccer/basketball highlights by sport. However, it lacks an explicit action verb (e.g., 'Get', 'List'), instead using a noun phrase, and the intended operation is implied rather than stated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the tool name and the example showing a date-based query. There is no explicit guidance on when to choose this over other highlightly_* tools, though the sport-specific naming makes alternatives obvious. No exclusion or alternative tool is mentioned, so guidance is largely implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• highlightly_hockey_highlightsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value beyond these by disclosing the unverified response shape and the need for a personal HIGHLIGHTLY_API_KEY. It also warns that the returned structure is approximate and should be inspected. This goes beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: purpose statement, return shape, caveat, example, and auth note are each distinct and logically ordered. It is concise overall, though the vendor-docs caveat is a bit wordy. Every section earns its place, keeping it within a reasonable length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description compensates by providing a return shape with key fields, a note about verification, an example call, and authentication requirements. It covers the essential information needed to select and invoke the tool, though it could briefly mention that it is hockey-specific or that pagination behavior is not detailed. Overall, it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers all four parameters with descriptions (e.g., date as YYYY-MM-DD, limit as 'Page size'), giving 100% coverage. The description adds a usage example for 'date' but does not enrich the meaning of matchId or leagueId beyond their schema descriptions. Baseline 3 is appropriate since schema handles the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Ice-hockey highlight clips,' which clearly identifies the tool's domain and resource. It distinguishes from sibling tools like highlightly_soccer_highlights and highlightly_basketball_highlights by specifying the sport. However, it lacks an explicit verb like 'retrieve' or 'list,' relying on the noun phrase to imply the action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete example ('A day's hockey highlights' with a date parameter) that implies typical usage, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. No mention of sibling highlightly tools or exclusion criteria, so guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• jolpicaf1_racesA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, idempotent, and open-world hints. The description adds that no authentication is needed and specifies the exact return structure, which is useful. It also notes data availability from 2021 for session times, providing extra context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose and includes a compact return structure and example. The return schema is somewhat verbose but adds value in the absence of an output schema. No redundant sentences.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with good annotations and full schema coverage, the description is complete: it states the purpose, shows the output shape, gives a concrete example, and notes authentication. Minor gaps like pagination behavior are not critical given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for all three parameters. The description does not add meaningful parameter details beyond the schema, as the example merely repeats the season and format values. The baseline of 3 applies because the schema fully documents each parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns a season's race calendar with dates, circuits, and session times. This distinguishes it from sibling tools like jolpicaf1_results and jolpicaf1_qualifying, though it lacks an explicit verb like 'list' or 'get'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example and the note that 'round is what the result tools take' imply this is a precursor to result/qualifying/sprint tools, but there is no explicit statement about when to use this tool versus alternatives. The usage context is implied rather than directly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_exchange_announcementsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly, openWorld, idempotent), the description adds useful context: it specifies that announcements are 'active' (not historical) and includes an explicit 'Auth: none needed' note, which addresses authentication requirements. The return shape is also given, providing behavioral clarity without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is minimal yet complete: a clear definition, a structured return description in a concise format, and an auth note. Each sentence serves a purpose with no redundancy or unnecessary filler. It is well-front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity, the comprehensive annotations, and the presence of a return format in the description, it is largely complete. The only minor gap is not clarifying how 'active' announcements relate to time or whether they are updated dynamically, but the openWorldHint partially covers this. Overall, the description gives sufficient context for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema is empty with 100% coverage by definition. The baseline for zero parameters is 4, and the description appropriately does not need to explain parameters. It adds no irrelevant parameter information, which is correct.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the resource: 'Active exchange-wide announcements.' It specifies the type of data returned and includes a functional return format. While it lacks an explicit verb like 'list' or 'retrieve,' the meaning is unambiguous and distinct from sibling tools like kalshi_exchange_status and kalshi_exchange_schedule.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention the difference between announcements and status/schedule, nor any context for when announcements would be relevant. The only extra operational hint is 'Auth: none needed,' which is not a usage guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_exchange_scheduleA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond the annotations by specifying the return structure 'Returns: {schedule:{standard_hours, maintenance_windows}}' and explicitly stating no authentication is needed. This provides output shape and auth context not covered by the readOnlyHint, openWorldHint, or idempotentHint annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise, with just two lines of core content plus return type and auth. Every sentence is meaningful and front-loaded, with no redundancy or irrelevant details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter, read-only tool, the description provides the essential return structure and clarifies the schedule contents (standard hours, maintenance windows). It does not elaborate on timezone, date ranges, or interpretation details, but these are minor gaps given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the input schema trivially covers all parameters. According to the rubric, zero params earns a baseline of 4. The description correctly omits parameter details, and there is no need for additional param explanation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the resource and content: 'Standard trading hours + maintenance windows.' It conveys what the tool returns, but lacks an explicit action verb like 'get' and does not differentiate from sibling tools such as kalshi_exchange_status or kalshi_exchange_announcements. Thus it is clear but not distinguishing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. It does not mention use cases like 'when you need trading hours' or compare with kalshi_exchange_status. The only additional note, 'Auth: none needed,' relates to authentication rather than usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_player_game_statsA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is known. The description adds 'Auth: none needed' and a return structure, which is useful context. However, it does not describe edge cases (e.g., empty stats if player did not play) or any quirks about the data. Given the annotations, the description adds some value but not rich behavioral detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: two sentences plus a return type sketch. It front-loads the core purpose, provides a simple return shape, and includes an auth note. There is no fluff or redundant information, making it easy to parse and ideal for AI consumption.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, so the description must convey return value structure. It provides a high-level shape ({stats:[...]}) but lacks specific details on stat object keys (e.g., hits, ERA, fielding errors) and does not mention possible empty results or group types (batting/pitching/fielding are listed but not how they map). For a simple lookup with good annotations, this is sufficient but not complete enough to fully inform an agent of all possible responses.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and both parameters (personId, gamePk) have descriptions in the schema. The tool description does not add any additional parameter guidance or context beyond what the schema provides. Baseline 3 is appropriate since the schema handles the parameter semantics fully.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'One player's stat line for one specific game' with explicit mention of batting/pitching/fielding. This uses a specific verb ('returns') and resource ('stat line for one specific game'), and it naturally distinguishes from sibling tools like mlb_player_stats which likely cover broader scopes. The scope is unambiguous and immediately understandable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The use case is implied ('one specific game') but there is no explicit guidance on when to use this vs. alternatives. No exclusions or alternative tool names are mentioned. While an agent can infer the tool is for game-level stats, it does not say 'for season stats, use X' or 'do not use for boxscore'. This is adequate but not distinguishing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhl_standingsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, and the description adds useful behavioral context: 'Auth: none needed' and a detailed return object with all fields. It doesn't discuss rate limits or date interpretation nuances, but with strong annotations present, the description goes beyond the minimum.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a one-line summary, a compact return schema, an example, and auth note. No word is wasted, and the most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 listing every return field (teamName, points, divisionSequence, clinchIndicator, etc.). It also covers auth and provides an example. This is sufficient for a tool with one optional parameter and read-only semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the single 'date' parameter with format 'YYYY-MM-DD' or 'now' and a default. The description only repeats the 'now' example, adding no semantic meaning beyond what the schema already provides. This matches the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as league standings with division/conference/wildcard sequencing and clinch indicators, and the name 'nhl_standings' makes the sport unambiguous. It lacks an explicit imperative verb like 'Get', but the 'Returns:' clause effectively states what the tool does and distinguishes it from other standings tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an example for 'now' standings but provides no explicit guidance on when to use this tool versus alternatives like mlb_standings, pl_standings, or other standings tools. No exclusions or preferred contexts are mentioned, so the agent gets the result but not decision support.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opendota_pro_matchesA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/idempotent annotations, the description adds valuable detail: the exact return fields, the clarification that Dota sides are RADIANT and DIRE (not home/away), and that radiant_win is the result. It also states no auth is needed, which is helpful operational context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is reasonably concise, with a clear opening line and structured return field list. The 'Example: Latest pro matches' line is somewhat filler, but the overall text is efficient and front-loaded with the key purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple read-only nature, one optional parameter, and strong annotations, the description is complete enough. The return fields are enumerated, the auth requirement is stated, and the pagination parameter is documented in the schema, so an agent has sufficient context to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides a complete description of the only parameter (less_than_match_id) with pagination semantics. The tool description adds nothing extra about parameters, so the schema carries the full burden, yielding baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns recent professional matches with teams, league, duration, and result. The inclusion of 'professional' distinguishes it from the sibling tool opendota_public_matches, so the resource and scope are specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool versus alternatives like opendota_public_matches or opendota_match. The name and description imply it is for pro matches, but there is no direct comparison or exclusion of other tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_teasersA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds that no authentication is needed and provides the return shape as a top-level array with example fields, which is useful behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a clear definition, followed by a returns section and an auth note. Every sentence serves a purpose, and it is front-loaded with the core meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, zero-parameter reference tool, the description is adequate: it explains purpose, return format, and authentication. It does not detail the nested league object fields, but the provided return example compensates for the lack of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema description coverage is 100%, so there are no parameter semantics to clarify. The description appropriately says nothing about parameters, and the baseline for zero-parameter tools is met.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource: teaser bet definitions, further specified by sport group and team count. It lacks an explicit verb like 'get' or 'list', but the noun phrase is unambiguous and distinguishes this tool from sibling Pinnacle tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus alternatives. It simply states what the tool provides without any context about when an agent should select it over other Pinnacle or sports-data tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_current_gameweekA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by stating 'static config blob' (implying the value does not change frequently) and explicitly noting 'Auth: none needed', which simplifies invocation. This is useful context beyond the annotations and does not contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, using only two short sentences plus return and auth notes. Every element earns its place: it states what the tool returns, labels it as a config blob, and confirms no authentication is required. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, annotation-rich tool, the description is mostly complete. It specifies the output format ({matchweek}) and the static nature. However, it does not explain what a matchweek number is or how it might be used (e.g., for scheduling comparisons), which could be helpful for an agent unfamiliar with the domain. Given the simplicity, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description is not expected to explain parameter semantics. The baseline for zero-param tools is 4, and the description appropriately focuses on the return value. No additional parameter information is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'the current matchweek number' and notes it returns {matchweek}. However, it uses a noun phrase rather than an imperative verb like 'Get' or 'Retrieve', making it slightly less direct. It distinguishes itself from siblings by being the only tool focused specifically on the current matchweek.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is provided on when to use this tool instead of alternatives. The phrase 'static config blob' hints that this is a config value rather than live data, but there is no mention of alternatives such as pl_matchweek_matches or pl_metadata. The 'Auth: none needed' line is a prerequisite hint, not a usage guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_teamformA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the tool is established as a safe read operation. The description adds valuable context beyond annotations by documenting the return shape ([{id, name, shortName, abbr, form, next}]), clarifying it's a top-level array, and noting 'Auth: none needed.' The field names in the return type are briefly explained by the natural language ('recent results + next fixture per team'), though field semantics like form's format aren't detailed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tight and well-structured: a single value-proposition sentence, then a brief structured return block, then an auth note. Every line earns its place. The parenthetical '(the table's form guide)' is slightly redundant with the first clause but harmless. Could be marginally tightened, but overall it's efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with 2 required params, no output schema, and no nested objects, the description covers the key bases: batch scope, return shape, top-level array structure, and auth requirements. It maps 'form' and 'next' in the return to natural language meanings. Minor gaps exist (e.g., no mention of ordering or form field format), but with annotations covering the read-only safety profile, this is adequate for agent use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — the schema already documents both cid ('Competition id (8)') and sid ('Season id (2025 = 2025/26)') with required status and URL path context. The description itself adds no parameter-level information, but the baseline is 3 when the schema fully covers parameters. No value added beyond the schema, but none needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb (returns a batch of all teams' form) and resource (season form guide: recent results + next fixture). 'Every team's form for the season in one call' establishes the all-in-one-batch scope, which differentiates it from sibling pl_team_form (which implies a single team). Slight deduction because it doesn't explicitly name the contrast with that sibling, but the singular/plural distinction is strongly implied.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool ('every team's form... in one call' signals a batch/table-view use case) but never explicitly states when to avoid it or names alternatives like pl_team_form or pl_standings. It successfully conveys 'all teams at once' vs alternatives, yet the guidance is implied rather than stated. Context could be clearer for an agent deciding between this and the many sibling PL tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• polymarket_clob_marketsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, open-world, and idempotent behavior, and the description adds valuable context beyond that. It discloses cursor-paginated behavior, the return structure, and that no authentication is needed, which are not covered by annotations. This goes beyond the baseline and gives the agent practical behavioral expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the core purpose, followed by a useful return format and auth note. The structure is generally clean, but the unclear 'Also answers this: kalshi_markets.' line adds confusion and could be considered extraneous, preventing a perfect score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema provided, the description carries the burden of explaining return values, which it does comprehensively by listing the exact fields and structure. It also covers pagination and authentication, making it sufficiently complete for a simple one-parameter read-only catalogue tool. The only gap is a lack of explicit sibling differentiation, but this does not severely hamper invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides a thorough description of next_cursor, including special values ('' for first page, 'LTE=' for end), covering 100% of the parameter. The description only reinforces the cursor-paginated nature without adding new parameter-specific details. Per the rubric, high schema coverage sets a baseline of 3, and the description does not exceed that.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a CLOB market catalogue with specific content (condition ids, token pairs, tick sizes) and pagination. It distinguishes itself as 'the trading-plane view of the same markets,' which implies a sibling tool but does not explicitly name it. The phrase 'Also answers this: kalshi_markets' is cryptic and could confuse rather than clarify the core purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides implied usage context through 'trading-plane view of the same markets' and the cross-reference to kalshi_markets, but lacks explicit guidance on when to choose this tool over alternatives. There are no clear exclusions or alternative tool names mentioned. The reference to kalshi_markets is ambiguous and does not offer actionable selection criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• polymarket_midpointA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral context beyond these: auth requirements, the return shape {mid}, and the cross-tool behavior of also answering kalshi_orderbook requests. No contradiction with annotations is present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very short and front-loaded with the core purpose, followed by labeled return and auth lines. The final sentence 'Also answers this: kalshi_orderbook' is potentially confusing but does not significantly bloat the text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter read-only tool with strong annotations, the description adequately covers purpose, return shape, and auth. It lacks detail on edge cases such as empty order books or the type/range of the midpoint, but given the simple scope and schema richness, it is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter token_id is fully described in the schema as 'CLOB token id,' so schema coverage is 100%. The description's reference to 'one outcome token' adds minimal semantic value and does not clarify format, sourcing, or edge cases beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning the midpoint between best bid and best ask for one outcome token, which distinguishes it from siblings like polymarket_price, polymarket_spread, and kalshi_orderbook. However, it lacks an explicit verb and the closing 'Also answers this: kalshi_orderbook' introduces ambiguity about scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no explicit guidance on when to use this tool versus sibling tools like polymarket_price or polymarket_spread. 'Auth: none needed' addresses prerequisites, and 'Also answers this: kalshi_orderbook' hints at cross-tool routing, but this is only implied context, not clear usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sleeper_user_leaguesA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnly, idempotent, and openWorld hints. The description adds 'Auth: none needed' and explicitly shows the return array fields, contributing useful behavioral context without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured, including a returns list and a concrete example. The only minor waste is the misleading 'from a username' phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool without an output schema, the description covers the key return fields, auth, and an example. It is complete enough to invoke correctly, though it could clarify the source of user_id.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has 100% coverage with useful descriptions, so the baseline is 3. The description's example demonstrates realistic values but doesn't add deeper parameter semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it lists all leagues for a user filtered by sport and season, with the specific use case of deriving a league_id. However, the phrase 'from a username' contradicts the actual parameter which requires a numeric user_id, per the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides a clear implied use case: 'how you get a league_id from a user.' It does not explicitly mention alternatives like sleeper_league or sleeper_user, nor any exclusions, so the guidance is sufficient but not fully explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportmonks_leaguesA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/idempotent annotations, the description adds critical caveats: the return shape is from vendor docs and unverified, and it notes the auth requirement (SPORTMONKS_TOKEN). This discloses uncertainty and prerequisites that are not present in the annotations, providing meaningful behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a one-line purpose, a structured return shape block, a caveat note, an example, and an auth line. It is front-loaded and each element carries useful information, though the 'Example: Leagues on your plan' line is somewhat redundant with the opening sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a detailed return shape including pagination fields, which is essential for an agent. It also includes a reliability caveat, auth note, and free-tier example. The field names are self-explanatory, so missing field-level explanations are acceptable, making this quite complete for a list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all three parameters (page, include, per_page) with examples and constraints (e.g., 'max 50'). The description does not add extra parameter-specific meaning, so with 100% schema coverage the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource being returned ('Leagues your plan can see') and provides concrete examples (Danish Superliga, Scottish Premiership on free tier). It distinguishes from sibling sportmonks tools by focusing specifically on league-level data, though it lacks an explicit verb like 'gets' or 'lists'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives useful context about plan-based visibility and a free-tier example, which implies when an agent might expect limited results. However, it does not explicitly state when to use this tool versus other sportmonks endpoints, nor does it name any alternatives or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_cms_settingsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds useful context beyond annotations: 'Auth: none needed' and a defined return shape `{settings:{}}`. It doesn't detail what settings or feature flags are included, but it adds meaningful behavioral information.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short lines: purpose, return type, and auth. Every sentence is informative with zero filler, and the purpose is front-loaded. This is a model of conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter settings read, the description covers purpose, return shape, and auth. However, without an output schema, the agent doesn't know the structure of `settings` or what 'feature flags' entail. The annotations indicate openWorld and read-only, which partially compensate. Overall, sufficient for the tool's simplicity but not exhaustive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool takes 0 parameters and the empty schema fully covers them. With no parameters to document, the baseline is 4. The description adds no parameter semantics, but none are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Global CMS settings / feature flags' which identifies the resource, and 'Returns: {settings:{}}' clarifies the outcome. However, it lacks an explicit verb like 'get' or 'retrieve' and does not differentiate from other similar settings tools like nrl_application_settings or supercoach_settings, so it's not a perfect 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. Sibling tools like sportsbet_cms_page and sportsbet_cms_messages exist, but no exclusions or references are given. The 'Global' prefix implies broad scope, but it doesn't tell the agent when to invoke this tool specifically.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_racing_megabetsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the read-only/idempotent annotations, the description adds the auth requirement ('Auth: none needed') and the exact return structure (megabets with legs and winPrice), which is useful behavioral context. It doesn't cover edge cases like empty results, but the added details are meaningful.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a clear definition, the return shape, and auth requirement. Every sentence serves a purpose with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter, read-only tool, the description provides essential return structure and auth info, making it mostly self-contained. It lacks usage context and differentiation from sibling tools, preventing a higher score, but is adequate for a simple retrieval operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the description correctly implies no inputs are needed. The schema already covers this, so the baseline of 4 applies; the description adds no parameter-specific information but also doesn't need to.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description defines Racing Megabets as 'large multi suggestions across races' and shows a return shape, making clear it retrieves suggested multi-bets. However, it lacks an explicit verb like 'Get' or 'List', and doesn't distinguish it from sibling tools such as sportsbet_racing_best_bets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives like sportsbet_racing_best_bets or sportsbet_racing_popular_srms. It only notes that auth is not needed, which is a prerequisite but not usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_safer_gambling_messageA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare read-only, open-world, and idempotent behavior. The description adds valuable context by specifying the exact return shape ({message:{title, body}}) and stating that no authentication is needed, which goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, containing only three short statements (purpose, return structure, auth requirement). Every sentence is relevant, there is no padding, and the structure is cleanly organized.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no parameters and no output schema, the description effectively communicates the essential information: what it is, what it returns, and its auth requirements. It could optionally mention whether the message is static or varies by user, but for such a simple tool, the coverage is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline for this dimension is 4. The description does not need to explain parameters, and it does not, making it appropriate for the simple interface.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (the site's current safer-gambling message block) and its return structure, distinguishing it from the many sports data tools in the sibling list. However, it lacks an explicit action verb like 'get' or 'retrieve', relying on the word 'Returns' to imply fetching, which keeps it just below top tier.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives, no exclusions, and no stated context beyond the inherent purpose. The description simply states what it returns, offering no practical usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsdataio_nba_dfs_slatesA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint/openWorldHint/idempotentHint annotations, the description discloses that the return shape is from vendor docs and unverified, and instructs to inspect the actual payload. It also specifies authentication requirements via the SPORTSDATAIO_*_KEY environment variables, adding valuable context about prerequisites.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The first sentence is front-loaded and clear, but the description includes redundant caveats about the unverified vendor shape ('SHAPE FROM VENDOR DOCS' and the subsequent NOTE). At ~130 words, it's verbose for a single-parameter tool, though each substantive section (Returns, Example, Auth) serves a purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a detailed return shape, an example call, and auth instructions, covering most operational needs. It lacks usage guidance and error handling, but for a simple read-only tool with one parameter, it's reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers the single 'date' parameter with format and requirement. The description reinforces it with a concrete example ('2024-01-15') and mentions 'for a date,' adding mild value beyond the schema. However, since coverage is 100%, the baseline is 3 and the example only slightly elevates it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'NBA DFS slates and salaries for a date,' which clearly specifies the resource and scope. The Returns section confirms it produces a list of slates and player salaries, distinguishing it from the NFL sibling tool by NBA in the name. However, it lacks an explicit verb like 'get' or 'list,' so it's not maximally explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving NBA DFS slates for a given date but offers no explicit when-to-use guidance or alternatives. There is no mention of the sibling sportsdataio_nfl_dfs_slates or any exclusion criteria, leaving the agent to infer applicability from the purpose line. This is an implied usage rather than clear guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_league_draftA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark readOnlyHint and idempotentHint, so the description does not need to restate safety. It adds valuable context: the return shape is unverified vendor documentation, actual payloads should be inspected, and auth requires the user's own YAHOO_CLIENT_ID, YAHOO_CLIENT_SECRET, or YAHOO_REFRESH_TOKEN.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is fully lead with a one-sentence summary, followed by a clear but somewhat verbose response shape, an explicit unverified caveat, an example, and an auth note. Each element has a purpose, and the shape is useful because no output schema exists.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description supplies the vendor-documented response shape, an example call, and an honest caveat that the shape should be treated as approximate. That is adequate for a simple read-only endpoint and avoids over-claiming on unverified details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents leagueKey as required and part of the URL path, and format as 'json'. The description only reinforces leagueKey through the example `{"leagueKey": "449.l.12345"}` and adds no new syntactic or behavioral detail about parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening line, "Draft results — every pick in order with round, team and player," clearly identifies the resource and the exact data returned. It distinguishes this tool from other yahoo_league_* tools even though it lacks an explicit verb like 'get' or 'fetch.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for fetching Yahoo league draft results, but it never states when to prefer it over other yahoo league tools or whether it applies only to particular league types. It mentions an example and auth, but gives no explicit when/when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_league_standingsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint/openWorldHint/idempotentHint, so the description rightly focuses on additive value: a detailed (if unverified) return payload shape, an explicit caveat that the shape is from vendor docs and should be inspected at runtime, the auth requirement referencing specific env vars, and a usage example. This is genuinely useful behavioral context beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The content is front-loaded with a one-sentence purpose, followed by the return shape, caveat, and example. While the JSON blob is long, it is clearly valuable given the absence of an output schema, and the unverified-shape warning is important. It is organized and justifiably sized.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only standings query with no output schema, the description provides an approximate return structure, a prominent verification warning, example input, and authentication details. The only gap is a lack of explicit error/edge-case notes (e.g., invalid league key behavior), but for this complexity level it is quite complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with reasonable descriptions for both params (format: 'Leave as json.'; leagueKey: 'League key. Required — part of the URL path.'), putting this at baseline 3. The free-text description adds a concrete example value but doesn't meaningfully elaborate param semantics beyond the schema, which already carries the load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening sentence, 'Standings with each team's record, points for/against and playoff seed,' specifies the resource (standings) and its contents with an implied 'get/return' verb. It distinguishes itself from siblings like yahoo_league_settings or yahoo_league_teams by enumerating exact fields, though it stops short of naming alternatives explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied through the description and the included example call ({"leagueKey": "449.l.12345"}) and auth env-var guidance, but there is no explicit when-to-use vs. alternative tool (e.g., no mention of yahoo_league_teams for rosters). The auth note hints at prerequisites but not when this tool is preferred.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_player_ownershipA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to restate those. It adds valuable transparency by warning that the return shape is unverified, that the provider key is not held, and that the payload should be inspected before relying on field names. It also discloses auth requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average but well-structured with clear sections: summary, return shape, caveat, example, and auth. Every section earns its place, especially the unverified-shape warning and example. The dense return-shape block is necessary because there is no output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description compensates by providing the vendor-documented return shape, a caveat about its reliability, a usage example, and auth instructions. It is complete enough for a simple read-only lookup, though it does not cover error cases or pagination.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with each parameter already described in the input schema. The description adds a concrete example with realistic leagueKey and playerKeys values, but it does not add substantive semantic meaning beyond 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's resource: ownership and roster status for league players, including percent owned and whether they are rostered, on waivers, or free. It is specific enough to distinguish from sibling tools like yahoo_player_stats or yahoo_team_roster, though it does not explicitly name or contrast those alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example 'Is this player available?' implies the primary use case, and the explanation of ownership_type ('add them now' vs 'you must outbid someone') provides practical context. However, there is no explicit when-to-use versus alternatives or any exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_team_statsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already establish read-only, idempotent, and open-world behavior, and the description adds valuable context: the returned shape comes from vendor docs and is unverified, authentication with a Yahoo key is required, and stat_id resolves via yahoo_game_stat_categories. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a short purpose statement, return shape, caveat, example, and auth note. Each section serves a clear function, and the most important caveat about unverified vendor shape is prominently highlighted.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the embedded return-shape definition and stat_id cross-reference are essential and mostly sufficient. The auth requirement, example call, and caveat about payload reliability make this a fairly complete description for a small 3-parameter stats fetch.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% parameter coverage, so a baseline of 3 is appropriate. The description's example ('{"teamKey": "449.l.12345.t.3", "type": "season"}') adds a realistic key format, but it does not explain the broader enum values such as 'date', 'lastweek', or 'lastmonth'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies that the tool provides a team's aggregated stats and includes a detailed return shape, which differentiates it from roster/matchup/player-stat tools. It lacks an explicit active verb like 'fetch' or 'list' and only mentions season/week even though the schema also supports date, lastweek, and lastmonth.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'team's aggregated stats for a season or a week' gives contextual reason to use it, but it does not explicitly say when to use it over alternatives or name any excluding cases. There is no direct comparison to sibling tools such as yahoo_team_roster, yahoo_team_matchups, or yahoo_player_stats.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_broadcasters_listA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, idempotent, and open-world behavior. The description adds value by noting auth is not needed and specifying the exact return shape (pageInfo + content array with fields). It does not discuss pagination or restrictedCountries semantics, but the annotations reduce the burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: a one-sentence purpose with examples, a return type line, and an auth line. Every part earns its place and the key information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one optional parameter and no output schema, the description covers purpose, return format, and auth. It omits pagination behavior and the meaning of restrictedCountries, but these are minor given the tool's simplicity and the schema's coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single parameter pageSize, which is described as 'Rows per page.' The description does not add further parameter details, but the schema already carries the meaning, so a baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'List broadcasters' with specific examples (Foxtel, Channel 7, BBC, ESPN) and shows the return structure, making it distinct from sibling tools that handle regions, channels, or events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like afl_broadcast_channels or afl_broadcast_events. The description only states what it does, without any context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_rounds_listA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds value by specifying the exact return fields (including byes and times) and stating 'Auth: none needed,' which gives useful context beyond the annotations. It does not describe pagination behavior, but the schema covers pageSize.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the primary action, followed by the return format and auth note. Every sentence provides useful information without redundancy, making it easy to scan and process.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description, combined with the annotations and schema, gives an agent enough context to invoke the tool correctly. It includes the return shape and a clear statement of what is returned, while safety and idempotency are covered by annotations. Minor gaps like pagination defaults are handled in the schema, making this a well-rounded description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all three parameters with clear descriptions at 100% coverage, so the baseline is 3. The tool description adds no additional parameter meaning beyond the schema; it simply references 'a comp season,' which is already captured in the compSeasonId parameter description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists rounds for a comp season, including byes and start/end times. It uses a specific verb and resource, and the name aligns. However, it does not explicitly distinguish it from sibling tools like afl_compseason_get, 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by identifying the resource ('rounds for a comp season') but provides no guidance on when to prefer it over alternatives, nor any exclusions. The note about auth is minor and does not help with tool selection. It is adequate but not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_venues_listA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds useful context: 'Auth: none needed' and the exact return structure `{venues:[{id, providerId, name, location, state, timezone, landOwner}]}`. This discloses the response shape and access requirements, adding 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: it leads with the core action, then provides the return shape and auth requirement in a structured format. Every sentence earns its place without fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with optional pagination parameters, the description is largely complete: it states the resource, fields, return structure, and auth. It could optionally mention pagination behavior, but the schema already covers that. The absence of an output schema is mitigated by the inline return type.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already has 100% description coverage for both parameters (page: 'Zero-based page number.', pageSize: 'Rows per page.'). The description adds no parameter-specific information beyond what is in the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'List venues (191) incl. location, state, timezone, landOwner.' The verb 'List' plus the resource 'venues' makes the purpose explicit. It also distinguishes from the sibling afl_venue_get by indicating this is a bulk list operation with specific fields.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like afl_venue_get. It only states 'Auth: none needed', which is not usage guidance. No mention of pagination or when the list is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• balldontlie_nfl_gamesA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations by disclosing the approximate, unverified return shape ('has NOT been verified against a live response') and the auth requirement (BALLDONTLIE_API_KEY). It also lists the specific fields the agent can expect. This is meaningful context not present in the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, followed by the return shape, a critical caveat, an example, and auth info. Every sentence serves a purpose with no redundancy. The structure (purpose → shape → note → example → auth) is logical and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 6 optional parameters, no output schema, and read-only annotations, the description covers the essential return fields, provides a usage example, and transparently notes the shape is unverified. It lacks explicit pagination loop instructions, but the presence of 'meta.next_cursor' and the cursor parameter in the schema mitigate that gap. The auth note is also included.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 a concrete example showing 'seasons' as an array of year strings, which clarifies usage. However, it doesn't explain interactions between filters (e.g., combining season and week) or add details about cursor pagination beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'NFL games by season, week or team,' which clearly identifies the resource (NFL games) and the main filtering dimensions. It lacks an explicit verb like 'retrieve' or 'list,' but the intent is unambiguous. It distinguishes itself from siblings by the sport, though it doesn't explicitly contrast with similar NFL tools from other providers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example 'A season's games' and filter options imply typical usage, but the description does not explicitly say when to prefer this tool over alternatives like apisports_nfl_games or sportsdataio_nfl_scores. No exclusions or when-not-to-use guidance is given, leaving the agent to infer the tool's niche from the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betfair_event_timelineA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already state readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds valuable detail beyond annotations by showing the return shape (nested score, timeElapsed) and stating 'Auth: none needed'. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: purpose in the first line, return example in the second, and auth in the third. Every part contributes useful information with no wasted words. The multiline return sample is structured and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (6 params, 100% schema coverage, no output schema, but with readOnly/idempotent annotations), the description covers purpose, return shape, and auth. It does not mention rate limits or error cases, but for a straightforward read-only tool, this is largely sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema descriptions cover all 6 parameters (100% coverage), including eventId as 'Single event id'. The description's mention of 'one in-play event' aligns with the schema but adds no deeper parameter semantics or new constraints beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Live timeline + running score/state for one in-play event', specifying the resource and singular scope. It differentiates from sibling tools like betfair_event_timelines by focusing on a single event, but lacks an explicit verb like 'Get' and does not name alternative tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for one in-play event' implies when to use the tool, but there is no explicit guidance on when not to use it or which alternative to choose. Sibling tools such as betfair_scores or betfair_event_details exist but are not referenced, leaving the agent to infer usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betfair_scores_broadcastA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable context by specifying the return array structure ({eventId, startTime, state:{score}, broadcast}) and stating 'Auth: none needed.' This goes beyond simply restating the annotations, though it stops short of describing edge cases like missing events or broadcast data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise lines: a one-sentence purpose, a return shape example, and an auth note. No wasted words, front-loaded with the most important information, and each sentence adds unique value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 reasonably by giving a return shape example. It also covers auth. However, it doesn't mention what sports/leagues are covered, how to obtain eventIds, or the meaning of the nested score/broadcast objects. Given the tool's moderate complexity, it's mostly complete but leaves some gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage with clear descriptions for all five parameters (e.g., eventIds as 'Comma-separated event ids', regionCode as 'Region'). The description's phrase 'one or more events' reinforces the eventIds parameter but doesn't add new meaning beyond the schema. Since the schema does the heavy lifting, the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides 'Live scores plus broadcast/streaming availability' for events, which is specific enough to distinguish from the sibling betfair_scores (scores-only). The return shape further clarifies the resource. However, it lacks an explicit verb and does not name any sibling alternative, so it doesn't fully earn a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied: you'd call this when you need scores and broadcast info for specific events. But there's no explicit statement of when to use this versus betfair_scores, afl_broadcast_events, or other related tools, and no exclusions or prerequisites. This is adequate but not explicitly guided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_all_promotionsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, open-world, and idempotent behavior. The description adds the specific return format and explicitly states 'Auth: none needed', providing useful context beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise, containing only essential information: the scope of results, the fields returned, the return type, and authentication requirements. Every sentence serves a purpose without redundant detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple parameterless read-only tool, the description is complete. It includes the return structure (crucial since no output schema exists), the scope, and the auth requirement. Combined with the annotations, it gives an agent sufficient understanding to invoke and interpret the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters in the schema, so the baseline is 4. The description reinforces the lack of filters by stating 'All visible promotions', which implies a broad unfiltered query, adding value for understanding the parameterless interface.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns all visible promotions with fields like name, description, and dates. The tool name 'betr_all_promotions' reinforces the all-inclusive scope, and the return structure is explicitly given, which distinguishes it from narrower promotion tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as betr_promotions or pointsbet_promotions. The description only states what it does, with no context about typical use cases or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_grouped_racecardA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent behavior. The description adds useful context beyond annotations by detailing the return shape (grouped by Thoroughbred/Greyhounds/Trots with fields), providing an example, and noting that no auth is needed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and compact: a one-sentence purpose, a return type definition, an example, and an auth note. Every part adds value with no redundant filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 providing the full return structure and an example, making the tool's behavior clear. It could mention edge cases like empty meetings or timezone handling, but for this simple day-offset tool it is essentially complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes DaysToRace with offset semantics, and the description does not add new parameter meaning beyond a usage example. Baseline 3 is appropriate given 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns 'all meetings + their races for a day offset, grouped by code,' with a specific return structure. This distinguishes it from sibling tools like betr_next5_races or betr_race by emphasizing the grouped, day-level scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no explicit when-to-use guidance or mention of alternatives. The description implies use for day-level grouped racecards, but it does not contrast with similar tools like betr_todays_races or entain_racing_racecard, leaving selection guidance missing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• chesscom_playerA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the tool read-only, idempotent, and open-world. The description adds useful context beyond these: 'Auth: none needed' and critical format caveats (joined/last_online are UNIX seconds, country is a URL rather than a code). It also enumerates the exact return fields, which is helpful.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with labeled sections (Returns, Example, Auth) and every sentence contributes value. It is concise and front-loaded with the primary purpose, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description covers the return shape, important field format nuances, an example, and auth requirements. It is sufficiently complete for correct selection and invocation, though it could optionally mention error behavior or data freshness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents the only parameter (username) with a clear description (lowercase, required, part of URL path). The description's example provides a concrete value but does not add significant semantic information beyond what the schema already states. With 100% schema coverage, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning a Chess.com player's profile and lists key fields, distinguishing it from siblings like chesscom_player_stats. However, it lacks an explicit verb like 'Get' or 'Fetch', relying on the noun phrase and the 'Returns:' section to convey the action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an example ('{"username": "hikaru"}') that implies usage for looking up a single player's profile, but it does not explicitly state when to use this tool over alternatives such as chesscom_player_stats or lichess_user. No when-not-to-use or alternative tool guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketaustralia_competitionsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which cover the safety profile. The description adds practical context beyond those: an explicit return shape including the array of competition objects and responseError, plus the note that no authentication is required. It doesn't discuss rate limits or pagination, but for a simple catalogue this is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: a one-line summary, a structured Returns section, and an Auth line. Every sentence serves a purpose, with no filler or repetition. It is exemplary in keeping the description short while still covering the key details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple read-only list endpoint with no required parameters and no output schema. The description provides the exact return structure, states auth requirements, and relies on annotations for behavioral traits. The only minor omission is any mention of result ordering or limits, but given the catalogue nature this is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 itself doesn't add parameter-level detail, but the schema already describes both parameters: format as 'Response format' and jsconfig as 'Response-shape flag (leave default)'. The description's Returns line adds some context about the format, but the parameters remain adequately covered by the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies a 'Competition catalogue' containing series/tournaments and enumerates the returned fields (id, name, url, imageUrl, startDateTime, endDateTime, order). The Returns line reinforces that this is a listing operation. It doesn't explicitly contrast with sibling tools like cricketaustralia_tours or other competition endpoints, but the tool name and content make the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: if you need a catalogue of competitions, use this tool. It does not provide explicit when-to-use guidance or name alternatives for related tasks (e.g., fetching fixtures or tours). There are no exclusions or prerequisites other than the positive 'Auth: none needed.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketaustralia_streamsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds useful behavioral context: streams are empty when the match isn't live, the return object shape, and that no auth is needed. This goes beyond the annotations and helps manage expectations without contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, front-loaded with the core purpose and followed by return format and auth. Every sentence earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with no output schema, the description covers the key aspects: return shape, empty-array behavior, fixture context, and auth requirement. It does not detail the structure of stream URLs/metadata, but the schema and openWorldHint provide enough for an agent to proceed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters (fixtureId and jsconfig) having descriptions. The tool description adds no extra parameter meaning beyond what the schema already provides, which aligns with the baseline of 3 when the schema fully documents parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool provides live video stream entries for a fixture, which is a specific resource. It clearly distinguishes this from other cricket tools like scorecards or fixtures by focusing on streams, though it lacks a strong verb like 'retrieve' or 'list'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates that streams are populated only during live matches, implying the tool is for live match usage. However, it does not explicitly name alternative tools for non-live scenarios or provide when-not-to-use guidance, which is a gap given the large sibling tool set.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketdata_scorecardA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only and idempotent behavior. The description adds context beyond these by stating that an API key is required ('needs your own key in CRICKETDATA_API_KEY') and warning that the response shape is from vendor documentation and has not been verified, advising the agent to inspect the actual payload.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is structured with purpose first, then return shape, abbreviations, warning, example, and auth. While relatively long, the information is relevant and organized, with the key purpose stated at the beginning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a detailed JSON return shape, explains cricket abbreviations, gives an example, and notes the unverified nature of the shape. This gives the agent sufficient context to handle the response, despite the lack of a formal output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema describes the single parameter 'id' as 'Match id.' The description provides an example call using {'id': '<match id>'}, but this adds little beyond the schema. Since schema coverage is 100%, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Full scorecard: batting and bowling figures per innings,' clearly identifying the tool's function. This distinguishes it from sibling tools like cricketdata_match_info and cricketdata_current_matches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives. It includes an example but does not explain when to use it over other scorecard or match tools, leaving the agent to infer usage from the name and purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_hist_odds_event_listA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds meaningful behavior details beyond annotations: the return format (top-level array) and the authentication requirement (DATAGOLF_KEY). No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: a single purpose sentence, a return-type line, and an auth line. Every sentence earns its place with no redundant or vague filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool, the description covers the essential points: what is listed, the return shape, and required auth. However, it does not clarify how the tour parameter filters the events or what archived_preds represents, leaving minor gaps despite schema coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions for tour and file_format. The description adds no additional semantic meaning about these parameters, so the baseline score of 3 applies as the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses a specific verb ('List') and clearly identifies the resource: 'historical events that have archived bookmaker odds available'. This distinguishes it from sibling tools like datagolf_hist_event_list, which lacks the odds qualifier. The example return fields further reinforce the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as datagolf_hist_event_list or datagolf_hist_results. It only mentions an auth requirement, not the contexts in which this tool is preferred.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_live_strokes_gainedA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool as read-only, world-open, and idempotent, so the safety profile is covered. The description adds valuable behavioral context: it requires an API key (DATAGOLF_KEY) and provides the response structure, including fields like current_round, last_update, and per-round strokes-gained data. This goes beyond the annotations and helps the agent understand the operational context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-sentence summary, a clearly labeled return shape, and an auth note. Each part serves a purpose: summary for quick understanding, returns for output expectations, and auth for prerequisite. It is front-loaded and avoids unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that there is no output schema, the description compensates by providing a detailed return structure with example fields and explains authentication. It covers the essential context for invoking the tool successfully. It does not elaborate on edge cases like empty events or pagination, but for a live data tool with no required parameters, the coverage is sufficient for an agent to know what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both 'sg' and 'file_format' are described in the input schema. The description repeats the sg distinction (raw vs relative) but does not add any new parameter details. According to the rubric, baseline 3 is appropriate when the schema fully documents the parameters, and the description provides no additional semantic value beyond that.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource: live strokes-gained data for every player in PGA Tour events. It uses a specific noun phrase 'Live strokes-gained breakdown' which is recognizable among sibling tools like datagolf_live_hole_stats and datagolf_live_tournament_stats, though the verb is implicit (retrieve/get is implied). It distinguishes itself by the focus on strokes gained.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use for live PGA Tour strokes-gained data, and the mention of 'raw or relative to model expectations' gives a hint at the sg parameter. However, it does not explicitly contrast with sibling tools like datagolf_live_tournament_stats or datagolf_in_play, nor does it state when not to use this tool. Context is present but exclusions and alternatives are absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entain_event_market_rulesA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, open-world, and idempotent behavior. The description adds useful context by specifying the return structure and stating that no authentication is needed, going beyond the annotation hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and to the point. It packs the purpose, return format, and auth requirement into three short sentences, with no superfluous content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, read-only reference tool with rich annotations, the description is fully sufficient. It explicitly defines the output structure, which compensates for the missing output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, and the input schema is empty, so the baseline is 4. The description does not need to explain any parameter semantics, and it correctly omits such details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool provides settlement rules for named markets indexed by rule ID. It is specific about the resource, though it lacks an explicit verb like 'retrieve' or 'list' and does not differentiate from sibling tools beyond the name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. It does not mention any use cases, exclusions, or related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espn_core_callA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, idempotent, and open-world behavior. The description adds valuable context beyond annotations: auth requirements ('none needed'), the $ref-linked envelope and the need to follow refs for detail, and a caution about the plural 'leagues' path. No contradictions 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single paragraph but well-structured, front-loading the purpose and scope. The enumerated content categories are dense but relevant, and the Note/Returns/Auth lines are clear. Slightly long, but no wasted sentences.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description compensates by explaining the response envelope ($ref, count, items) and how to access detail. It covers operation discovery, required inputs, and auth. It lacks pagination and rate-limit details, but for an open-world gateway with annotations, this is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers all three parameters with descriptions, but the tool description adds meaningful examples for path_params (sport, league, eventId/competitionId/athleteId/year) and explains the operation concept. It also directs users to the operations resource for valid operation names, which complements the schema's pointer to list_resources.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a gateway to the ESPN core data model, lists specific content areas (athletes, statistics, odds, plays, etc.), and notes the path uses 'leagues/{league}'. It distinguishes itself from other ESPN tools by naming the core API surface and instructing users to browse the espn://core/operations resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives practical guidance on how to use the tool (supply operation + path_params, follow $ref links, browse operations). It implies this is the canonical/deepest surface, but does not explicitly state when to choose this over sibling ESPN tools like espn_site_call or espn_web_call, nor when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_communicationA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds valuable behavioral context: the 404 error when no communication group exists, the exact return shape, and auth behavior (works without key, cookie unlocks more). This goes beyond the annotations and helps the agent anticipate edge cases.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is organized into clear sections: summary, return shape, example, and auth. It is efficient with no fluff, though the 404 condition is mentioned twice (once in the summary, once in the return note), which is a minor redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 supplies the return structure. It also covers the error case (404), provides a concrete example, and explains authentication. This is highly complete for a read-only data access tool, giving the agent everything needed to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, so parameters like game, seasonId, and leagueId are already well-documented. The description adds a concrete example with real values, which reinforces usage but does not introduce new semantic meaning. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as the league message board / activity feed with examples of contents (chat topics, trade chatter, activity posts). It distinguishes this from sibling espnfantasy tools by focusing on communication data. While it lacks an explicit verb like 'get' or 'list', 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a usage example and mentions authentication constraints, but it does not explicitly state when to use this tool versus alternatives such as espnfantasy_league or espnfantasy_teams. Usage context is implied through the resource name rather than explicitly contrasted.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_playersA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral details: the default 50-player limit, the role of fantasy_filter in widening/filtering, an example request, and the auth note that a key is not required but a cookie unlocks more. This goes beyond the annotations and does not contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is organized into a summary, return shape, example, and auth note, with the primary purpose front-loaded. Each section provides useful information; however, the example JSON and detailed field list make it slightly longer than strictly necessary. Still, there is no wasted repetition, and the structure is clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description supplies the return field list, and the schema covers all parameters. The description fills in the default size, a usage example, and authentication context. It does not discuss pagination or sorting beyond the schema's note about limit requiring sort, but for a list-retrieval tool with this schema and annotations, it is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds context by explaining the default 50-player limit and positioning fantasy_filter as the widening/filtering mechanism, plus a concrete default example. While the schema's fantasy_filter description is already detailed, the description reinforces the default-limit behavior and provides a quick-start example.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as the season's player universe and lists the fields returned, and the Returns section confirms it returns a top-level array. However, it lacks an explicit action verb like 'Get' or 'List', and it does not directly name sibling tools for differentiation, though the phrase 'player universe for a season' distinguishes it from player-specific tools like espnfantasy_player_info.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states the default 50-player limit and says to pass fantasy_filter to widen or filter, which implies when to adjust usage. However, it does not explicitly explain when to use this tool instead of sibling tools such as espnfantasy_rosters or espnfantasy_player_info, nor does it mention exclusions. Usage context is implied but not fully explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_rostersA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful behavioral context beyond the readOnly/openWorld/idempotent annotations: the response is explicitly flagged as LARGE (hundreds of KB), the auth behavior is disclosed, and the return shape is shown. The 'unlocks more' cookie note is slightly vague, but no annotation contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and compact: an overview, a size warning, a return shape, an example, and an auth note. Each section earns its place and the most important caveat (LARGE response) is front-loaded near the start.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even without an output schema, the description supplies a useful return-shape sketch, example request, auth note, and size warning. It does not discuss pagination, errors, or rate limits, but the essential context for invoking the tool is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already handles parameter semantics. The description adds a concrete example illustrating seasonId/leagueId/scoringPeriodId for a weekly roster request, but it does not add much beyond that baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource and scope: every fantasy team's roster with manager ownership, lineup slot, acquisition type, and player stats. It is distinct from sibling tools like espnfantasy_teams and espnfantasy_standings, though it lacks an explicit imperative verb like 'get' or 'list'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example ('All rosters, week 3') and wording 'Every fantasy team's roster' imply when to use this tool, but there is no explicit statement about when not to use it or what to use instead. The LARGE-size warning is useful, but the guidance is mostly implied rather than direct.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fanduel_racing_quicklinksA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds 'Auth: none needed', which is useful context. It also discloses a partial return structure ({quickLinks:[{label, url, ...}]}), giving agents a sense of the response shape 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and front-loaded with the core purpose. The return and auth notes are separate but compact, and every element earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool (no parameters, read-only, trivial return), the description is fully sufficient. It states the purpose, provides a return example, and mentions authentication, covering all necessary context for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters, the schema fully covers the input space, and the baseline for no-parameter tools is 4. The description appropriately does not invent parameter details, though it also doesn't explicitly state that no parameters are required (which the schema already shows).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as providing homepage quick-link tiles for the FanDuel racing site, which matches the tool name and distinguishes it from sibling racing tools for other brands. However, it lacks an explicit verb like 'retrieve' or 'list', and does not elaborate on the exact nature of the tiles beyond the return example.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. It does not mention any exclusions or point to other tools for related data, leaving the agent to infer usage solely from the name and description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_managerA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare this a read-only, idempotent, open-world operation. The description adds meaningful behavioral context beyond that: optional auth via FPL_SESSION_COOKIE, the detailed return structure, and the unit clarification for last_deadline_value/bank. No contradiction with annotations exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is organized into distinct sections (summary, return shape, unit note, example, auth) and front-loads the primary purpose. The return structure is verbose but necessary since no output schema exists. No filler sentences are present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only tool with no output schema, the description is thorough: it explains the full return object, units, auth behavior, and gives a concrete example. The only minor omission is the exact effect of the session cookie on the response, but this does not prevent correct invocation or interpretation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage for managerId is 100% and the schema already explains it thoroughly. The description's example merely restates the parameter and adds no new format or syntax information beyond the schema, so it does not elevate above the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns a manager's squad summary including overall rank, points, and leagues. It uses a specific resource ('manager's squad') and identifies the core outputs, though it does not explicitly contrast with sibling fpl tools like fpl_manager_history or fpl_manager_picks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied via the described purpose (use this to get a manager's squad summary), but there are no explicit when-to-use/when-not-to-use instructions or named alternatives. The auth note (works without a key; cookie unlocks more) is useful but not a substitute for selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• isportsapi_football_competitionsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond the readOnlyHint/idempotentHint annotations by documenting the return shape, the meaning of code:0, the HTTP 200 error delivery, and the caveat that the shape is unverified. It also discloses the auth requirement (ISPORTS_API_KEY). This is useful behavioral context, though the unverified warning is more about data reliability than tool behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections (Returns, NOTE, Example, Auth) and no wasted words. It conveys the essential purpose, return shape, caveat, and auth in a compact form. Every sentence contributes information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless list tool, the description covers what is needed: the resource, the return format, error semantics, and the unverified nature of the data. The example clarifies the scope, and the auth note covers a critical prerequisite. No output schema exists, so the description appropriately takes on the role of documenting return values.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema coverage is 100% (empty object), so the baseline is 4. The description adds no parameter details because none exist, which is acceptable. The return shape example partially compensates for the lack of an output schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides 'Football competitions with their ids', which is a specific resource and implies a list operation. The return shape with field names confirms this, but the description lacks a verb like 'list' or 'get' and does not differentiate this from other competition tools like pl_competitions or laliga_competitions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool versus the many sibling competition tools. The example 'Every competition' implies it returns all competitions, but there is no discussion of intended use cases, prerequisites, or alternatives. For a simple list tool, this is a partial gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_structured_targetA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnly, openWorld, and idempotent behavior. The description adds useful context: 'Auth: none needed' and the exact return shape '{structured_target:{id, name, type, details, source_ids}}'. These details go beyond the annotations and help the agent understand what to expect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and front-loaded. The main purpose is in the first sentence, followed by a clear returns line and an auth note. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter get-by-id tool, the description is complete: it states the resource being fetched, the return structure, and authentication requirements. It does not explain field semantics, but the lack of an output schema makes that less critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema description for 'id' already says 'Structured-target id. Required — part of the URL path.' The description's 'by id' adds no new semantic meaning. Baseline 3 is appropriate since the schema handles parameter documentation well.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'One structured target (entity) by id.' clearly indicating this tool fetches a single structured target by its id. It distinguishes from the sibling tool 'kalshi_structured_targets' by emphasizing singular 'One' and 'by id'. However, the verb is implied rather than explicit (e.g., 'get' or 'retrieve'), so a perfect score is not warranted.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: use this when you have a specific structured target id. No explicit alternatives or exclusions are mentioned, but the 'by id' phrasing provides basic context. It does not reference the sibling listing tool as an alternative, which would have been clearer.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_structured_targetsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly, openWorld, idempotent), the description adds useful behavioral context: 'Auth: none needed', 'Paginated by cursor; page size via page_size', and the response structure. This clarifies pagination behavior and access requirements, which the annotations do not cover. No contradiction exists 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is succinct and structured: a one-line definition, a pagination note, a return shape preview, and an auth note. Every sentence earns its place without redundancy. It fronts the core purpose immediately and remains compact.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of output schema, the description compensates by explicitly listing the return fields. It also covers pagination and auth, which are key contextual aspects. However, it does not mention when to prefer this tool over the singular kalshi_structured_target, which slightly limits completeness for an agent choosing among siblings.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already includes descriptions for all three parameters (type, cursor, page_size), and the description doesn't add new parameter-specific meaning. The phrase 'page size via page_size' repeats schema info, and the return format alone doesn't clarify parameter semantics. Since schema coverage is 100%, the baseline of 3 is appropriate; the description adds little beyond that.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as Kalshi's entity registry (players, companies, people) that markets resolve against, and its return format indicates a list operation. It distinguishes itself from the singular sibling kalshi_structured_target by being plural, though it doesn't explicitly compare to that sibling. The purpose is unambiguous but could state 'list' or 'retrieve' as the verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains the resource and pagination but provides no explicit guidance on when to use this tool vs alternatives like kalshi_structured_target. It implies usage for browsing or fetching entity registry entries, but does not state exclusions or contrast with other Kalshi lookup tools. Text: 'Structured targets — Kalshi's entity registry (players, companies, people) that markets resolve against' gives context but no when-to-use rules.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lichess_daily_puzzleA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent. The description adds the auth requirement ('Auth: none needed') and explicitly lays out the return structure, which goes beyond structured data. It doesn't mention timezone or reset behavior, but that's minor given the safety profile is covered.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and well-structured with a summary, return format, example, and auth line. The 'Example' field is vague but not harmful. It earns its place without unnecessary verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 listing all return fields under 'Returns:' with types and examples. It could clarify some field semantics (e.g., initialPly) but is largely complete for a parameterless daily puzzle fetcher.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so schema coverage is trivially 100%. Per guidelines, baseline for 0 params is 4; the description doesn't need to add parameter information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies the resource as the daily puzzle and lists its components (position, solution line, source game), and the 'Returns' section clarifies it's a retrieval operation. However, it lacks a direct verb like 'Get' and does not explicitly distinguish itself from other chess tools, though it's the only daily puzzle tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when the daily puzzle is needed, and the example 'Today's puzzle' suggests a simple call. However, there is no explicit guidance on when to use this vs. other Lichess tools, no exclusions, and no mention of daily update timing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_allstar_writeinsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds useful context beyond this: it specifies the exact return object structure and explicitly notes that no authentication is needed. This supplements the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, containing only the essential information: what the tool returns, the return shape, and authentication requirement. Every sentence earns its place with no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two well-documented parameters and good annotations, the description provides a clear return schema and auth requirement. It lacks only a brief explanation of what 'write-in candidates' means in the All-Star context, but this is a minor gap given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions, including season year and league id with allowed values (103=AL, 104=NL). The tool description does not add further parameter clarification beyond what the schema already provides, but this is acceptable given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource: All-Star write-in candidates for a league and season. It distinguishes this from sibling tools like mlb_allstar_ballot and mlb_allstar_final_vote by focusing specifically on write-ins. The return shape is also specified.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving write-in candidates for a given league and season, but it does not explicitly state when to use this tool over alternatives such as mlb_allstar_ballot or mlb_allstar_final_vote. No exclusions or alternative tool references are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_playerA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the return structure in detail, mentions that no auth is needed, and aligns with the readOnly and idempotent hints. It adds context by showing the exact response fields, which is valuable given no output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, front-loaded with the purpose, followed by a return shape and auth note. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple lookup with two parameters, the description is complete: it provides a mini-output schema, auth info, and the core constraints. It could mention error cases or hydrate effects, but those are largely covered by the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for both parameters: personId has a clear description and source hint, hydrate includes an example. The description adds little beyond emphasizing the single personId requirement, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a player biographical profile, listing the fields returned and requiring a personId. It distinguishes from sibling tools like mlb_player_search by focusing on biography rather than search, though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide explicit when-to-use or when-not-to-use guidance relative to the many sibling tools. It implies usage by saying 'One personId' (you need an ID first) but doesn't mention where to get it from or what other tools might be better for stats or rosters.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_schedule_postseason_tuneinA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, open-world, and idempotent behavior, and the description does not contradict these. It adds valuable context by stating 'Auth: none needed' and describing the return structure, but it does not disclose behavior when the optional 'season' parameter is null (e.g., defaults to current season).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose, followed by the return format and auth requirement. Every sentence serves a purpose with no redundancy or promotional content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with no output schema, the description covers the purpose, auth, and return structure. However, it does not explain the default behavior of the optional parameters, leaving a minor gap in how to invoke the tool without specifying a season.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters already documented ('Season year.' and 'Sport id (1 = MLB).'), so the baseline is 3. The description adds no additional information about parameter meanings, defaults, or how they affect the response.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as providing postseason broadcast 'tune-in' info (where/when to watch playoff games), which distinguishes it from sibling schedule tools like mlb_schedule_postseason and mlb_schedule_postseason_series. It lacks an explicit verb such as 'Get' or 'List,' but the resource and scope are clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied by the 'tune-in' framing and the return type, but there is no explicit statement of when to use this tool versus alternatives. No prerequisites, exclusions, or alternative tool names are mentioned in the description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_team_leadersA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare this as read-only, idempotent, and open-world. The description adds useful context: 'Auth: none needed' and a structured return shape. It does not go into further detail about edge cases or pagination, but given the strong annotations, this is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: two short sentences plus a return type and auth note. Every sentence earns its place, with no redundancy or fluff. The return format is clearly laid out, and the purpose is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with 5 parameters and no output schema, the description provides a clear return structure and example categories. It does not explain all possible categories or game types, but these are documented in the schema. The overall information is sufficient for an agent to select and invoke this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters are well-documented. The description adds value by providing example category names (homeRuns, era) and clarifies that limit is 'Top-N' in the schema. This is a marginal addition beyond the schema, aligning with the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: retrieving a team's statistical leaders for specified categories in a season. It is specific about the resource (team) and the operation (leaders), and the examples (homeRuns, era) clarify the expected categories. However, it does not explicitly distinguish itself from the sibling tool mlb_leaders, though the word 'team's' implies the difference.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you need a team's statistical leaders for given categories. It does not explicitly state when not to use it or mention alternatives like mlb_leaders for league-wide leaders. There are no clear exclusions or prerequisites beyond the implied team-level scope.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_team_uniformsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety is clear. The description adds useful behavioral context by specifying the return structure and stating that no auth is needed. It does not contradict 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise: two sentences plus a compact return type illustration. Every element serves a purpose—resource, scope, return shape, and auth requirements—with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description provides the return structure, which helps the agent anticipate results. It does not explain the behavior of the optional 'season' parameter (e.g., default handling), but overall it is reasonably complete for a simple lookup tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters described ('Team id(s).' and 'Season year.'). The description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the resource ('Uniform assets / descriptions') and scope ('for one or more teams'), clearly distinguishing it from sibling tools like mlb_team_roster or mlb_teams. However, it lacks an explicit action verb like 'fetch' or 'retrieve,' making it slightly less direct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when uniform assets are needed and notes that no authentication is required, but it does not explicitly state when to use this tool over alternatives or provide exclusions. No sibling alternatives are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_venuesA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds an explicit 'Auth: none needed' and the return shape. This is useful behavioral context beyond what the annotations provide, and there is no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two short paragraphs with a clear return type and auth status. Every sentence adds value, and the most important information (what it does and what it returns) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple venue lookup with no output schema, the description adequately explains the return structure and auth requirements. It does not cover edge cases like invalid IDs or pagination, but given the simplicity of the tool and the openWorldHint annotation, this is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — all three parameters (venueIds, season, hydrate) have descriptions. The tool description adds little parameter-specific meaning; it just restates that venueIds are used. Baseline 3 is appropriate because the schema carries the burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (venues) and the input (venueIds), and the return fields are listed. It lacks an explicit verb like 'get' or 'retrieve', and there is no direct comparison to other MLB tools, but the purpose is unambiguous for a venue lookup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you need venue details for one or more venue IDs. However, it does not explicitly state when not to use this tool or mention alternatives from the sibling list (e.g., mlb_teams for venue info via team endpoints). It provides clear context but no exclusions or alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mysportsfeeds_standingsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description goes beyond by disclosing that the return shape is unverified against a live response, warning the agent to treat it as approximate, and stating the auth key requirement. This adds valuable context about reliability and prerequisites.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized: summary, return shape, caveat, example, and auth. Each section adds value, and the format is easy to parse. Slightly longer than necessary but all content is relevant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description provides an approximate return shape, which helps the agent understand expected data. It also includes an example and auth requirements. Missing details like full season format options (e.g., '2024-2025') are minor; overall it's sufficiently complete for a read-only standings tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description adds an example showing a concrete invocation (league: 'nba', season: 'current') and the fact that 'current' is a valid season value. This clarifies usage beyond the schema's generic 'Season string' description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns standings for a league and season, with a concrete return shape and example. It is specific about the resource (standings) and scope, though it doesn't explicitly distinguish from sibling standings tools beyond the provider prefix in the name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied through the example and first line, and the auth note explains a prerequisite. However, there are no explicit exclusions or comparisons to alternative standings tools (e.g., pl_standings, nhl_standings), which would help an agent choose this tool over others.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opendota_heroesA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only and idempotent behavior, and the description adds useful context: a concrete return shape ('top-level array, ~127 heroes'), exact field naming ('localized_name', 'primary_attr'), and a no-auth note. This goes beyond the structured annotations to clarify output structure and scale.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: a lead phrase, a Returns block with a concrete example, a one-line usage example, and an auth note. Every sentence contributes information and there is no padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a parameterless, auth-free list endpoint. The description fully specifies the output fields, shape, and approximate size, which is sufficient for an agent to invoke it and interpret the result. No output schema exists, but the embedded return example compensates.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so there is nothing to document; the baseline of 4 applies. The description correctly spends no effort on parameters and focuses on the return payload instead.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as 'the hero catalogue' and enumerates the returned fields (id, name, primary attribute, attack type, roles), making the resource unambiguous. It does not explicitly contrast with sibling opendota tools like opendota_hero_stats, but the field list and 'catalogue' wording distinguish it effectively.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternative opendota tools. The 'Example: All heroes' line implies a general list retrieval, but there are no exclusions or references to siblings such as opendota_hero_stats for statistical hero data.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opendota_player_winlossA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool read-only, open-world, and idempotent. The description adds 'Auth: none needed' and the exact return shape {win, lose}, which is useful context but does not go beyond these basics. No rate limits or edge-case behaviors are mentioned.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: a one-line purpose, a clear return type, a practical example, and an auth note. Every sentence adds value with no fluff or repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While there is no output schema, the description explicitly documents the return structure and provides an example. Combined with full parameter descriptions in the schema and strong annotations, the tool is well-specified for an agent to invoke correctly. It lacks only deeper behavioral caveats, but these are not essential for this simple read-only endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% parameter coverage with descriptions for limit, hero_id, and account_id. The description adds minimal extra parameter meaning, only referencing 'same filters as their match list' without detailing them, so it does not significantly surpass the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's purpose: returning a player's win/loss totals. It also distinguishes itself from sibling tools by noting it uses the same filters as the match list, which is a specific, actionable scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (when needing win/loss aggregates) via its phrasing, and it references the match list for filter context. However, it does not explicitly state when not to use it or name alternative tools beyond an indirect reference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_overtakesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the agent knows this is a safe, read-only operation. The description adds the return format and states no auth is needed. It does not disclose pagination, rate limits, or edge cases like 'latest' behavior beyond what schema already says. This 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences and a return-type list. Every part earns its place: purpose, return fields, and auth note. It is front-loaded and free of fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple filtered-list tool with 4 params and no output schema, the description is reasonably complete. It includes the return array shape, which compensates for the lack of output schema. It doesn't cover every possible edge case, but the annotations and schema fill most gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all four parameters are already documented (session_key, meeting_key, overtaken_driver_number, overtaking_driver_number). The description adds no additional parameter semantics, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Overtake events in a race — who passed whom, when, and for which position.' This is a specific verb-resource pair and distinguishes it from sibling OpenF1 tools (laps, pit, position, etc.) by focusing on overtakes. The return format is also explicitly listed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context implies usage: fetch overtakes for a race session, optionally filtered by driver numbers. However, there is no explicit comparison to alternatives like openf1_position or openf1_laps, nor any 'when not to use' guidance. The presence of a required session_key is clear from schema, not described.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_positionA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds the return format (array of specific fields) and explicitly notes that no authentication is needed, which are useful. However, it does not disclose potential large result sets, pagination behavior, or the strong recommendation to filter by driver_number beyond what the schema provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and well-structured: a one-line purpose, a return format list, and an auth note. Every sentence contributes value with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity, full schema coverage, and strong annotations, the description covers the essential points: what data is returned and that no auth is needed. It includes a return field list, which compensates for the lack of an output schema. It doesn't mention practical filtering guidance (e.g., strongly recommending driver_number), but that is already in the schema, so the description is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema fully documents all parameters and their descriptions. The description does not add information about parameters beyond the schema, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool's specific function: retrieving driver track position over time within a session, with the core concept 'position changes throughout a session.' This clearly distinguishes it from sibling openf1 tools like openf1_location or openf1_car_data, which cover different data types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for tracking position changes across a session, but provides no explicit when-to-use guidance or comparison with alternatives. It does not state when not to use it or mention related tools, though the context makes the primary use case reasonably clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openligadb_matchdaysA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, open-world, and idempotent behavior, which the description complements by adding specifics like the exact return fields ([{groupID, groupName, groupOrderID}]), the meaning of groupOrderID, and that no auth is needed. This adds meaningful context beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and well-structured: it explains the purpose, shows the return shape, provides a concrete example, and states auth requirements in a few lines. Every sentence earns its place with no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple nature of this tool (2 params, no output schema, no nested objects), the description is complete enough: it covers return fields, example usage, and auth. It also provides cross-references to how the result connects to match tools. Minor details like the meaning of groupID are left unexplained, but the tool's scope is simple.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage for both parameters, including the fact that season is required. The description adds an example with actual values and clarifies that groupOrderID is the matchday number, but doesn't add significant new parameter semantics beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool returns the matchdays ('groups') in a season, with a specific verb ('returns') and resource ('matchdays in a season'). It distinguishes itself by clarifying OpenLigaDB's terminology ('Spieltag' = 'group') and indicates the return structure. However, it does not explicitly differentiate from siblings like openligadb_current_matchday, 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example showing a Bundesliga season and the note that groupOrderID is used by 'match tools' imply when to use this tool, but the description doesn't explicitly state alternatives or when not to use it. The usage context is implied rather than explicitly explained.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openligadb_tableA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations declare read-only and idempotent, but the description adds non-obvious behavior: results are ordered top to bottom, and the semantics of `goals` vs `opponentGoals` are clarified. The 'Auth: none needed' note also adds practical context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the primary purpose, followed by the return shape, ordering note, an example, and auth status. Every sentence contributes unique information with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with 2 parameters and no output schema, the description covers the return fields, ordering, an example, and auth requirements. The only minor gap is a lack of enumerated `league` shortcut values, but the default 'bl1' mitigates that.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% field description coverage, so the description does not need to repeat those details. It adds an example and reiterates that `season` is required and part of the URL path, but provides no additional valid values for `league`, leaving the schema as the primary source.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning a league table for a season, which is distinct from sibling tools focused on matchdays, matches, or teams. The noun phrase lacks an explicit verb but the return field list makes the operation unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete example and states that no auth is needed, implying usage for fetching a league table. However, it does not mention alternatives or when not to use this tool, so the guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pandascore_teamsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context: the return shape is from vendor docs and unverified, requiring payload inspection, and auth via PANDASCORE_TOKEN is required. This goes 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is structured with separate sections for return shape, caveat, example, and auth. All sentences are informative; no fluff, though slightly long.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with 4 optional parameters and no output schema, the description provides return shape, example, auth, and a verification caveat. Pagination is implied via page/per_page in schema. It's sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 100% coverage, but the description adds a concrete example for filter_videogame ('csgo' for CS2), clarifying the slug format. Other params are adequately described in schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Esports teams with their current rosters' and provides the return shape, clearly indicating this tool retrieves team data with rosters. This distinguishes it from sibling tools like pandascore_players and pandascore_matches, though it's a noun phrase rather than an explicit verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an example ('CS2 teams' with filter_videogame: 'csgo') implying when to use it, but doesn't explicitly compare with alternatives like pandascore_players or pandascore_leagues. No exclusions or when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pandascore_tournamentsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, open-world, and idempotent behavior. The description adds valuable context beyond this: the return shape is from vendor docs and unverified, advises inspecting actual payloads, and specifies the auth requirement (PANDASCORE_TOKEN). This is useful behavioral caveat not present in annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: purpose, return shape, reliability caveat, example, and auth. It is longer than minimal but every sentence adds value, and the caveat about unverified shape is important. The main purpose is front-loaded, though the format could be tightened.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a detailed return shape, which is essential. It also includes an example, auth requirement, and an explicit warning about data reliability. Missing is any guidance on when to use this tool instead of sibling Pandascore endpoints, but the core functional context is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameters (page, per_page, filter_videogame) already have descriptions. The description adds a concrete example ({"filter_videogame": "lol"}) and clarifies that filter_videogame is a title slug, reinforcing the optional one-title filter. This goes slightly beyond schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning tournaments (upcoming, running, past) with optional filtering by title, which distinguishes it from sibling Pandascore tools like matches, series, and leagues. The verb is implied rather than explicit ('Tournaments' as a noun phrase), but the resource and scope are specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through the phrase 'optionally for one title,' which maps to the filter_videogame parameter. However, it does not explicitly state when to use this tool over alternatives like pandascore_matches or pandascore_series, nor does it mention any exclusions or prerequisites beyond an auth key.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_matchupA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, idempotent, and openWorld hints. The description adds valuable behavioral context by specifying 'Auth: none needed' and the exact return shape, which is particularly useful since there is no output schema. It doesn't contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: a one-sentence summary, a return structure line, and an auth line. Every sentence earns its place, and the key information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With a single well-documented parameter, strong annotations, and a detailed return shape in the description, the tool is well-covered. The only minor gap is that 'periods' is shown as '[...]' without further detail, but overall the description is adequate for a simple single-resource read tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description already fully explains the parameter: 'Matchup id (from any matchups feed). Required — part of the URL path.' The description doesn't add extra meaning beyond implying the singular matchup context, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'One matchup's detail' and lists the key fields returned, conveying a specific verb+resource. It distinguishes itself from sibling list/matchup tools by emphasizing singularity, though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: you must have a matchupId 'from any matchups feed' as stated in the parameter description, and this tool returns the basic detail of that matchup. However, there is no explicit guidance on when to choose this instead of related tools like pinnacle_matchup_markets or pinnacle_matchup_related.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_sport_matchups_liveA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context beyond this: 'Auth: none needed' and the exact return shape. It clarifies that only live/in-play events are returned, which is a behavioral trait not fully captured by 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, front-loaded with the core purpose, and uses minimal lines to convey the return structure and auth requirement. Every sentence provides relevant information without repetition or padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description appropriately documents the return fields explicitly (id, league.name, participants, startTime, isLive, liveMode). Combined with the auth note and simple single-parameter schema, the description gives a sufficiently complete picture for a live-list read tool, though pagination and error behavior are not mentioned.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the schema already explains sportId is from pinnacle_sports_live and required. The tool description adds no extra parameter detail beyond the phrase 'for one sport', so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as live (in-play) matchups for a single sport, which distinguishes it from siblings like pinnacle_sport_matchups (likely scheduled) and pinnacle_sport_matchups_all (all sports). However, it does not explicitly name alternative tools, so the differentiation is implied rather than stated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for one sport' gives a hint that this tool is for live matchups filtered by a single sportId, contrasting with broader tools like pinnacle_sport_matchups_all. But there is no explicit guidance on when to use this versus alternatives, nor any exclusions or prerequisites beyond the sportId.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_awardsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/idempotent annotations, the description adds concrete behavioral details: it explicitly states the return shape ({player_awards:[…], manager_awards:[…]}) and that no authentication is required. This helps the agent know what to expect and that no credentials are needed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: one line for purpose, one for return structure, one for auth. Every sentence adds distinct value with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read-only tool with no output schema, the description provides the essential context: purpose, return format, and auth requirement. It does not mention potential edge cases like empty arrays or ordering, but those are minor for this type of tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover both parameters fully, explaining cid as competition ID and sid as season ID with examples. The tool description adds no additional parameter information, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as season awards (Player/Manager of the Month and other honours), which is distinct from any sibling tool. However, it lacks an explicit verb like 'get' or 'list', relying on the noun phrase and 'Returns:' to imply retrieval.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: if you need season awards for a given competition and season, this is the tool. There is no explicit comparison to alternatives or exclusion guidance, but the unique resource makes the use case fairly obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_metadataA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, idempotent, and open-world behavior. The description adds that no authentication is needed and specifies the return structure, which goes beyond the annotations. No contradictions are present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, with three short sentences covering purpose, return format, and authentication. It is front-loaded with the main purpose and contains no unnecessary prose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description adequately covers return format and auth, which is important since there is no output schema. However, the term 'generic entity metadata' is vague and the return structure uses an ellipsis, leaving some ambiguity about the full contents. For a simple two-parameter read-only tool, this is sufficient but lacks exhaustive detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes both parameters with 100% coverage. The description's mention of type constraints simply reiterates the schema. No additional parameter semantics are provided beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves entity metadata for football players and teams, explicitly listing the accepted types (SDP_FOOTBALL_PLAYER, SDP_FOOTBALL_TEAM) and the return content (external/fantasy profile links). This gives a specific verb+resource, though it doesn't explicitly differentiate from sibling pl_* tools beyond the 'generic' qualifier.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for fetching generic entity metadata but does not explicitly state when to use this tool versus alternatives like pl_player or pl_team. There is no 'use this when' or exclusion guidance, so usage is only implied from the context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_news_latestA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that no auth is needed and reveals the return shape, which are helpful supplemental details. There is no contradiction with annotations, and no destructive behavior is implied.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded, opening with the tool's purpose and immediately providing return structure, an example, and auth requirements. No fluff or redundancy. Every sentence serves a purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only feed tool, the description covers the core need: what it returns, an example call, and auth status. The absence of an output schema is mitigated by the explicit field list. It could elaborate on the 'smart-ranked' algorithm or tag syntax, but that is not essential for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully described in the schema (100% coverage), so the description's role is minimal. The example with 'limit': 5 provides a concrete usage illustration but does not add new semantics beyond the schema. Baseline score of 3 is appropriate given the schema carries the load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning the latest news with a smart ranking, described as the homepage feed. It lists the return fields, making the resource and action unambiguous. It does not explicitly contrast with siblings like pl_news_popular, but the 'latest' vs 'popular' distinction is implied.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives context that this is the homepage feed for latest news, but it does not specify when to prefer this over siblings such as pl_news_popular or pl_content. No exclusions or alternative tool mentions are provided. The example and auth note add some context, but usage guidance is mostly implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_standingsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description provides the full response return shape, explains the effect of live=true (folding in in-progress matches), and notes that no authentication is needed. These details complement the readOnlyHint and idempotentHint annotations without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a short definition, a returns block, an example, and an auth note. It is somewhat lengthy but each section earns its place, and the code blocks make it scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only standings tool, the description is quite complete: it specifies the output schema, live behavior, auth requirements, and a concrete example. A minor gap is not pointing to how to discover valid cid/sid values (e.g., via pl_competitions), but this is not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers all three parameters with 100% description coverage. The description adds concrete context by mapping cid=8 to the Premier League and sid=2025 to the 2025/26 season, going beyond the schema's field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns the league table for a season and specifies the entry structure, making the tool's purpose unambiguous. It does not explicitly differentiate from other standings tools, but the pl_ prefix and example (cid=8, sid=2025) convey Premier League context effectively.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied through the example and the live parameter explanation, indicating when to fetch live standings. However, it lacks explicit guidance on when to use this tool over alternatives like pl_competitions or other sports' standings tools, nor does it state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_video_latestA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only and idempotent behavior, so the description adds value by stating 'Auth: none needed' and showing the return format. However, 'smart-ranked' is never explained, and there is no detail on how tags filter results or pagination behavior beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: purpose, return shape, example, and auth note all in four short lines. Every sentence earns its place and the structure is scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool, the description provides enough context with return format, example, and auth. It lacks a definition of 'smart-ranked' and does not specify whether multiple videos are always returned, but overall it is sufficient given the schema and annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers both parameters with descriptions (100% coverage), so the baseline is 3. The description's example demonstrates limit usage but does not clarify tags semantics or ranking impact beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource ('Latest video') and adds 'smart-ranked' to indicate a specific ordering, distinguishing it from siblings like pl_video_popular and pl_news_latest. The verb is implied but the 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool versus alternatives such as pl_video_popular or other video tools. It provides an example and auth note but relies on the agent to infer usage from the name and 'latest' keyword.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• polymarket_eventA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, idempotent, and open-world behavior. The description adds 'Auth: none needed' and an explicit return shape, which are useful beyond the annotations. It does not disclose potential errors, rate limits, or pagination, but for a simple read operation the provided information is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two sentences plus a compact return list. It front-loads the core action, includes only essential details (return fields and auth), and contains no redundant wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter lookup with no output schema, the description covers the essential context: what is returned (including a representative field list), authentication requirements, and the data source. It does not explain error handling or edge cases, but given the simplicity of the tool, the information is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single parameter 'id,' and the schema description already explains it is a Gamma event id from polymarket_events, required, and part of the URL path. The tool description adds no extra meaning beyond saying 'by Gamma id,' so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'One event by Gamma id, with all its markets,' clearly identifying the resource (an event) and its scope (including markets). It lacks an explicit verb like 'get' or 'fetch,' but the noun-phrase form is unambiguous and distinguishes it from the sibling polymarket_events (plural). The return field list further clarifies what is produced.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage—fetch a single event with its markets by supplying a Gamma id—but does not explicitly state when to choose this tool over alternatives like polymarket_events or polymarket_market. The schema description adds a hint that the id comes from polymarket_events, but there is no direct when-to-use or when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• polymarket_marketsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds useful context beyond these: it states no authentication is needed, lists the returned fields in detail, and provides a concrete example. It does not disclose potential rate limits or error behavior, but for a read-only catalogue tool this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections: a one-line summary, return format, example, auth note, and a cross-reference. It is moderately concise and every part adds information. The 'Also answers this: kalshi_markets' line is slightly extraneous but does not significantly bloat the description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description compensates by listing the exact return fields and noting the top-level array shape. It also covers auth, provides an example, and mentions filtering options. It does not explain every parameter, but the schema already does that, making this reasonably complete for a list/filter tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage of all 15 parameters, so the baseline is 3. The description adds extra value by summarizing the main filtering dimensions (activity, volume, liquidity, tag, slug) and by including a concrete example that ties several parameters together (limit, active, closed, order, ascending), helping the agent understand how to combine them.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides a market catalogue with current outcome prices and lists filtering/sorting options. It identifies the resource (Polymarket markets) and distinguishes from most siblings, though the note 'Also answers this: kalshi_markets' introduces ambiguity about its exact scope relative to that tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context on what the tool can do (filter/sort by activity, volume, liquidity, tag, slug) and includes an example query. However, it does not provide explicit guidance on when to use this tool versus alternatives; the phrase 'Also answers this: kalshi_markets' is vague and could confuse an agent about when to prefer this tool over the Kalshi-specific sibling.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• polymarket_tradesA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavioral context beyond the annotations: it specifies the response shape (top-level array with listed fields), states authentication is not required, and clarifies the tool is for public data. It does not contradict the read-only, open-world, or idempotent hints, and usefully supplements them with return-format and auth details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise: each sentence delivers distinct information (purpose, return shape, auth, cross-reference). It is front-loaded with the core purpose and avoids redundancy with the schema or annotations.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only trade tape with 5 optional parameters and no output schema, the description covers the essential context: what data is returned, that it is public, and that no auth is needed. However, it does not mention default time ranges, ordering, or pagination behavior beyond what the schema implies, leaving minor completeness gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already describes all 5 parameters. The description adds minimal extra meaning by saying filtering can be by 'market (condition id) or user', which mirrors the schema's 'market' and 'user' descriptions. No meaningful additional parameter semantics are provided beyond the structured schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns recent trade fills ('Public trade tape') with optional filtering by market or user, and explicitly lists the return fields. However, it lacks a specific verb like 'list' or 'get', and the note 'Also answers this: kalshi_trades' adds slight ambiguity about its exact scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it (when you need recent trade fills) but never explicitly states when to use it over alternatives. The 'Also answers this: kalshi_trades' note hints at covering kalshi_trades-style queries, but the usage context is not clearly defined.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• seriea_competitionsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds 'Auth: none needed' and specifies the return structure, which goes beyond the readOnlyHint and idempotentHint annotations. It does not contradict any annotations. It lacks details on pagination or regional coverage, but these are not critical for a simple listing endpoint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the tool's purpose, followed by a clear return format and an auth note. Every sentence earns its place with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only listing endpoint, the description provides the essential return contract and auth status. It does not explain that the locale parameter affects label language, but the schema covers that. Overall it is sufficient for an agent to understand the tool's output and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single optional locale parameter is fully described in the schema with 'Label language' and a default value, so the description does not need to elaborate. The tool description adds no additional semantic context beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning all Lega Serie A competitions (Serie A, Coppa Italia, Super Cup, Primavera) with their SDP competitionId. This specific verb+resource scope distinguishes it from sibling tools for other leagues and from related Serie A tools like seriea_seasons or seriea_standings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is provided on when to use this tool versus alternatives. While the description implies listing competitions, it does not mention exclusions, alternatives, or prerequisites. Sibling tools such as seriea_competition or seriea_seasons are not referenced, leaving the agent to infer the intended use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sleeper_playoff_bracketA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, idempotent, and open-world behavior. The description adds value by disclosing the exact return format ({r, m, t1, t2, w, l, t1_from, t2_from}) and explaining the meaning of each key. It also notes 'Auth: none needed,' which is a practical behavioral detail 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is mostly efficient, with a clear purpose line, a compact return format spec, and an example. However, the final line 'Also answers this: espnfantasy_matchups, espnfantasy_matchup_score.' is cryptic and does not earn its place; it is likely confusing to an agent and reduces overall clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the rich annotations and full schema coverage, the description is fairly complete. It provides the return format, which compensates for the lack of an output schema, and includes an example and auth note. It does not mention error cases (e.g., no playoff bracket available), but for a simple read-only tool this is not a significant gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of parameters, so the baseline is 3. The description gives an example bracket value ('winners_bracket') but does not add meaningful semantic detail beyond the schema. The league_id parameter is described in the schema as 'part of the URL path,' and the description does not elaborate further.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'The playoff bracket — who plays whom in each round, and who advanced.' This is a specific verb+resource with a clear scope. It also distinguishes itself from siblings like sleeper_matchups by focusing on the playoff bracket specifically, and the 'Also answers this' line hints at its relationship to fantasy matchups tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an example call and notes that no auth is needed, giving basic usage context. However, it does not explicitly state when to use this tool over alternatives like sleeper_matchups or espnfantasy_matchups. The 'Also answers this' line is ambiguous and does not clearly guide tool selection. No exclusions or alternative recommendations are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sleeper_transactionsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, and the description does not contradict them. It adds useful context by noting 'Auth: none needed' and providing the return structure, which is helpful given there is no output schema. The added value is modest but above baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose. The return format, example, and auth note each serve a distinct informative role without redundancy. It is appropriately concise for a simple tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter read-only tool with no output schema, the description covers the essential aspects: what it returns, the return structure, an example invocation, and auth requirements. However, it lacks explicit usage guidance and the week caveat ('returns whole season in some leagues') resides only in the schema, not the description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both league_id and week described in the schema. The description provides an example call but adds no new parameter-level meaning beyond the schema. The baseline of 3 applies since the schema handles the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves 'Adds, drops, waiver claims and trades for one week,' using a specific verb-like enumeration and scope. This distinctly differentiates it from sibling tools like sleeper_matchups or sleeper_traded_picks. The return format further clarifies the resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus other Sleeper tools, nor any exclusions. The example and description imply it is for fetching weekly transactions, but no alternatives are mentioned, such as directing users to sleeper_traded_picks for traded picks specifically.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_class_couponA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already include readOnlyHint, openWorldHint, and idempotentHint, so the safe read-only nature is covered. The description adds value by showing the exact response shape and explicitly stating 'Auth: none needed,' which goes beyond the annotations. No contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: one line for purpose, one compact return structure, and one auth note. Every sentence contributes meaningful information, and the most important part (purpose) is front-loaded. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description explicitly provides the return JSON structure, which greatly aids the agent in understanding the response. It also covers auth requirements. For a simple read-only tool with a single parameter, this is adequately complete; error conditions or pagination are not necessary here.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the classId parameter already described as 'Sport class id. Required — part of the URL path.' The tool description adds no further parameter details beyond the context of the whole sport class. Since the schema fully documents the parameter, the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this tool returns a 'Coupon (grouped markets) for a whole sport class.' It identifies the resource (sport class coupon) and provides a concrete return structure, distinguishing it from sibling tools that target sports or competitions. No explicit differentiation from similar siblings, but the scope is specific enough.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when needing class-level grouped markets, but it does not explicitly state when to use it versus alternatives like sportsbet_sport_card or sportsbet_competition_matches. No exclusions or prerequisites are mentioned, leaving the when-to-use scenario somewhat inferred from the 'whole sport class' phrasing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_competition_matchesA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is established. The description adds the return schema and the auth requirement ('Auth: none needed'), which are valuable behavioral details beyond the annotations. No contradictions exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: a one-line purpose, a return shape, and an auth note. Every sentence earns its place with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter, read-only tool, the description covers the purpose, return shape, and auth requirement. It does not specify event ordering or time frame, but these are not critical given the simple scope and the openWorldHint annotation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the single parameter competitionId with a description noting it is required and part of the URL path. The tool description adds no additional parameter semantics, so reliance on the schema is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool returns 'Match-type events for a sport competition', clearly identifying the resource (matches) and the scope (by competition). It lacks an explicit verb like 'list' or 'get', but the context makes the operation clear and the phrase 'match-type' helps distinguish it from related tools like outrights or results.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used to fetch match events for a specific competition, but provides no explicit when-to-use guidance or alternatives. Sibling tools like sportsbet_event_results or sportsbet_competition_outrights serve different purposes, but the description does not mention when to choose this one over them.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_competition_outrightsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already set safety expectations (readOnly, openWorld, idempotent). The description adds 'Auth: none needed' and a concrete nested return structure, which is useful behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with purpose, and includes a structured return example. No fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the single-parameter API, read-only annotations, and the return structure explicitly listed, the description provides sufficient context for invocation. Could mention how to discover competitionId, but not essential for a simple read.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema fully describes the competitionId parameter with type and requirement. Description adds no additional parameter semantics beyond the schema, but schema coverage is 100%, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly identifies the tool as returning outright/futures events for a competition, with a detailed return structure. Distinguishes from sibling tools like sportsbet_competition_matches by specifying 'outright (futures)'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides no explicit when-to-use or alternative guidance, but the description makes it obvious for fetching futures/outright markets. Implied usage rather than explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_event_statusA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/openWorld/idempotent annotations, the description discloses the exact return shape ({eventId, status, inPlay, suspended}) and notes that no authentication is needed. This adds useful behavioral context without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and well-structured, with three clear sections: what it does, return format, and auth. Every sentence provides essential information with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, one-parameter, read-only status tool, the description is complete: it covers the purpose, return shape, and auth. It lacks details about possible status values or error handling, but these are not critical given the simple nature and existing annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single required parameter eventId. The description does not add any additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides live status flags for a sport event, explicitly listing the statuses (suspended, in-play, settled). This is a specific resource + action that distinguishes it from sibling tools like sportsbet_event_results or sportsbet_event_markets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or competing tools. The description simply states what it does, leaving the agent to infer usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_nav_hierarchyA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description supplements the readOnlyHint, openWorldHint, and idempotentHint annotations by explicitly disclosing the return structure (a JSON object with a 'nav' array) and the fact that no authentication is required. This adds meaningful context beyond the annotations, though it does not cover potential edge cases like response size 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, consisting of a one-line purpose statement and a compact return structure. Every sentence adds value, and the format is well-organized with clear separation of return type and auth requirement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no input parameters and a simple, well-defined output, the description is fully complete. It provides the exact return shape, confirms no authentication is needed, and aligns with the annotations. No additional context is required.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters, the schema provides no ambiguity, and the baseline for parameter semantics is high. The description does not need to explain parameters, and the absence of any parameter-related text is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning a sports navigation hierarchy structured as a class-to-competition tree, which is specific enough to distinguish it from sibling tools like sportsbet_sports_classes or sportsbet_sport_competition. However, it lacks an explicit verb, relying on the 'Returns:' clause to convey the action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides minimal usage context by stating 'for menus', but it does not explicitly say when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. No sibling comparisons or conditional guidance are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_popular_promotionsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already signal read-only and idempotent behavior, and the description adds 'Auth: none needed,' which is extra context. It also documents the exact return format, compensating for the lack of an output schema. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short lines: a purpose, a return type, and an auth note. Every sentence adds value; no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple read-only list tool; the description provides the return format and auth requirement, which is adequate given the annotations. However, it does not explain the behavior of optional parameters like limit and loggedIn beyond the schema, so it's not fully complete for complex use cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of parameters, so the baseline is 3. The description does not add any parameter semantics beyond what the schema already states (e.g., 'Required — part of the URL path'). It only refers to 'promo provider + client' referring to provider and clientId.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns trending/popular promotions for a provider and client, and specifies the return shape. This distinguishes it from sibling tools like sportsbet_event_markets or pointsbet_promotions by its focus on popular promotions. The verb 'Returns' and the structured output make the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or a preferred context (e.g., 'use when you need active promo campaigns'). This leaves the agent to infer from the name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_racing_competitionA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context beyond those by specifying the exact response structure (competition and events) and stating that no authentication is needed. It does not speculate about edge cases or errors, but for a simple read operation this is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences plus an auth line. It front-loads the purpose, then the return format, then auth. Every sentence provides necessary information with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one required parameter, no output schema, annotations providing safety profile), the description covers purpose, return structure, and auth. It lacks error handling details or examples, but these are not essential for such a straightforward retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% because competitionId has a detailed description ('Required — part of the URL path'). The description adds little beyond confirming the lookup is by competition id and using it in the return structure. The schema already handles the parameter semantics well.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Racing competition (meeting) detail by competition id') and provides the exact return shape. It is specific and distinguishes the tool from broader racing endpoints by focusing on a single competition's details and its events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given about when to use this tool versus the many similar sibling tools (e.g., sportsbet_racing_event_meeting, sportsbet_racecard). The description implies its use for fetching meeting details but does not mention alternatives, exclusions, or typical scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_sports_classesA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that no auth is needed and shows the return structure, which is useful. It also uses an example to convey that results are scoped to a date window with events, though the filtering behavior is not explicitly stated.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, with two sentences plus a concise example and auth note. The purpose is front-loaded, and every element (purpose, return format, example, auth) adds value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with strong annotations and full schema coverage, the description provides purpose, return format, a practical example, and auth requirements. It lacks explicit detail on how the optional boolean parameters alter results, but that information is in the schema. Overall, it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description's example demonstrates the date format but does not add new meaning to includeLiveEvents or excludeNonLiveEvents beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns sport classes (sports) with their competitions for a date window, and provides the return shape {classList:[{classId, className, classDisplayOrder}]}. This identifies the resource and scope, though it doesn't explicitly differentiate from sibling tools like sportsbet_sports_card or sportsbet_class_coupon.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example 'Sports with events in the next 24 hours' illustrates a concrete use case, and 'Auth: none needed' provides a prerequisite. However, there is no explicit guidance on when to use this tool instead of alternatives, nor any exclusions or when-not-to-use statements.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_live_events_summaryA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds useful context about authentication requirements (works without a key, but TAB_CLIENT_ID/SECRET unlocks more), which is valuable beyond the annotations. It also specifies the return structure, which is helpful.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-line purpose, a return structure snippet, and an auth note. Every sentence adds value, no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only summary tool with one optional parameter and no output schema, the description covers the essentials: what it returns, auth requirements, and the parameter. It could mention that the jurisdiction affects which events are returned, but the schema already covers that. Overall, it's complete enough for the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage for the single parameter (jurisdiction), so the description doesn't need to add much. The description doesn't elaborate on jurisdiction beyond the schema's 'State jurisdiction' but the schema is sufficient. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides a summary of live/in-play events across sports, with a specific return structure. It distinguishes itself from siblings like tab_sports_next_to_go or tab_match by focusing on a live summary across all sports, though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for getting a high-level overview of live events, but doesn't explicitly state when to use this vs. other live-event tools like tab_sports_next_to_go or pinnacle_sport_matchups_live. It mentions the jurisdiction parameter but doesn't clarify when to change it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_multi_builderA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnly, openWorld, and idempotent behavior. The description adds valuable context beyond annotations: auth behavior (works without a key, credentials unlock more) and the return shape. No contradictions detected.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose. The return and auth notes are each one line, with no redundant phrasing. Every sentence contributes useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read tool, the description covers purpose, return shape, and auth requirements. It could be more precise about what 'multi-builder markets' entails and what jurisdiction values are valid, but it is adequate for invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and both parameters have descriptions. The schema already documents sport with examples and jurisdiction with 'State jurisdiction.' The tool description does not add much beyond this, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource: multi-builder items for a single sport, including suggested legs/combinations. It also specifies the return fields. However, it lacks an explicit action verb like 'fetch' or 'list', which slightly reduces clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for retrieving multi-builder suggestions per sport, giving context for when to use it. It does not explicitly mention alternatives or when not to use it, such as comparing to tab_match_markets or tab_recommendation_featured.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_racing_datesA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds valuable behavioral context beyond the readOnlyHint, openWorldHint, and idempotentHint annotations by specifying the return structure ({dates:[{meetingDate, dateName, _links:{meetings}}]}) and authentication behavior ('works without a key; TAB_CLIENT_ID or TAB_CLIENT_SECRET unlocks more'). This helps the agent understand output shape and auth prerequisites, which is not in 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-clause purpose statement, a return-type block, and a note on authentication. Every sentence provides distinct, non-redundant information, with the most important detail (what this returns) front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one optional parameter, the description is complete: it explains what is returned, the shape of the result, and the authentication model. It does not explicitly state the default jurisdiction (NSW) but that is in the schema. Given the absence of an output schema, the included return-type snippet is valuable and sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (the jurisdiction parameter has a clear description of allowed values). The tool description does not mention the parameter at all, so it adds no extra semantic value beyond what the schema already provides. Per the calibration baseline, a score of 3 is appropriate when the schema is complete.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (racing dates) and its scope (dates with meetings), and differentiates from sibling tools like tab_racing_meetings by focusing on dates that link to meetings. It lacks an explicit imperative verb like 'Get' or 'List,' but the noun-phrase style is unambiguous and well-scoped.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (list racing dates that have meetings) but provides no explicit guidance on when to use this tool versus alternatives such as tab_racing_meetings or tab_racing_next_to_go. It gives no exclusions or alternative references, only an implied use case from the name and summary.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_racing_jackpotsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and open-world behavior; the description adds useful context by stating that the tool works without an API key and that setting TAB_CLIENT_ID or TAB_CLIENT_SECRET unlocks more access. No contradiction exists, though it stops short of describing pagination or data freshness constraints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: one for purpose and one combining return shape with auth info. It is front-loaded, compact, and every phrase adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-optional-parameter read-only tool, the description covers purpose, return structure, and auth requirements in a compact way. It is slightly incomplete because it doesn't clarify how the optional jurisdiction parameter filter interacts with the 'across meetings' scope, nor does it differentiate among the many sibling racing tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There is only one optional parameter and its schema description already covers the meaning ('State jurisdiction'). The description adds no further meaning about allowed values, how the jurisdiction affects results, or the interplay between jurisdiction and 'across meetings', so it remains at the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource: current racing jackpot/carryover pools across meetings, and includes a return-shape hint. It does not use an explicit verb like 'get' or 'list' and offers no direct comparison to sibling TAB tools, so it is clear but not fully differentiated within the family.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes it obvious when to use the tool: whenever current jackpot/carryover pool information is needed. However, it provides no explicit when-not-to-use guidance or mentions alternatives, leaving the agent to infer how this differs from the many other TAB racing tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_sports_resultsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses authentication behavior (works without a key, with optional keys for more data) and the return shape. This goes beyond the annotations, which only indicate read-only, idempotent, and open-world hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, consisting of a clear statement of purpose, the return structure, and an auth note. It is well-structured and does not include unnecessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool, the description provides sufficient context: purpose, output structure, parameter description (via schema), and authentication. It does not explain every edge case, but the essentials are covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The sole parameter 'jurisdiction' is adequately described in the schema as 'State jurisdiction.' The tool description does not add further clarification, but the schema coverage is complete, so a baseline score is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: it returns recently resulted sport events with final scores or settled markets. It also provides the return structure, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide any explicit guidance on when to use this tool over alternatives. It lacks context about exclusions, prerequisites, or specific scenarios where this tool is preferred.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_quote_tweetsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds valuable context by specifying the exact return shape ({data:[{id, text, author_id, public_metrics}], meta:{result_count, next_token}}) and stating the authentication requirement (X_BEARER_TOKEN). This goes beyond the structured fields and helps the agent understand pagination and output layout.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and well-structured: a one-line purpose, a clear 'Returns' block with the response schema, and an 'Auth' note. No extraneous words or repetition of schema details. Every sentence earns its place, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list endpoint with no output schema, the description is quite complete: it states the resource, the return structure, and authentication. It also hints at pagination via next_token in the meta. It could have mentioned that results are paginated via the pagination_token parameter, but the schema already documents that. Overall, it provides sufficient context for most use cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides full descriptions for all 4 parameters (id, max_results, tweet_fields, pagination_token), so the schema carries the heavy lifting. The description does not add extra meaning to the parameters beyond the schema, such as format details or inter-parameter dependencies. It does implicitly reference id via 'a given post', but this is marginal.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description "Posts quoting a given post" clearly indicates the tool retrieves posts that quote a specific post, aligning with the tool name and the required 'id' parameter. It distinguishes from sibling tools like twitter_tweets or twitter_search_recent by focusing specifically on quote tweets. However, the phrasing is slightly ambiguous ('posts' as verb vs noun) and doesn't explicitly state 'list' or 'retrieve'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by naming the resource (quoted post) and including parameters like max_results and pagination_token, suggesting a paginated listing operation. However, it does not explicitly state when to prefer this tool over alternatives such as twitter_search_recent or twitter_tweets, nor does it provide exclusions or preconditions beyond the auth note.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_retweeted_byA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the description does not need to restate safety. It adds value by disclosing the auth requirement (X_BEARER_TOKEN) and the exact return structure, which are not covered by annotations. It does not mention pagination or rate limits, but these are secondary.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise, using just three lines: a clear purpose statement, the return format, and an auth note. Every sentence contributes meaningful information with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only Twitter lookup with full schema coverage and strong annotations, the description provides sufficient context: purpose, return shape, and auth. It does not explicitly clarify the retweet vs. quote tweet distinction or pagination, but these are partially addressed by sibling names and the schema. Overall adequate for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with clear descriptions for id, max_results, and user_fields. The description adds no additional parameter semantics beyond what is already in the schema, aligning with the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the tool's function: returning users who reposted a given post. It distinguishes itself from sibling tools like twitter_liking_users and twitter_quote_tweets by using the specific term 'reposted'. The return format is also provided, adding clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool versus alternatives. The description does not mention when to choose this over twitter_liking_users or twitter_quote_tweets, nor does it provide exclusions. Usage is implied only through the stated purpose, which offers minimal direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_tweetA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful behavioral context: the exact return shape ({data: {...}, includes: {users}}) and the auth requirement (X_BEARER_TOKEN). This goes beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: three short sentences covering purpose, return shape, and auth. No irrelevant detail, front-loaded with the key purpose statement. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only single-post lookup, the description is complete given the rich annotations, fully described schema, and explicit return shape. It lacks some edge-case context (e.g., error handling, rate limits), but these are not critical since the schema and annotations cover the rest.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all four parameters. The description does not add additional parameter semantics beyond the schema, but the return shape hint (includes users) indirectly relates to the expansions parameter. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'One post by id' which clearly identifies the tool as retrieving a single post by its ID. It lacks an explicit verb but is specific enough to distinguish from plural/list tools like twitter_tweets. The 'by id' scoping is clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied: use this when you need a single post by ID. However, there is no explicit comparison to alternatives such as twitter_tweets or twitter_search_recent, nor any mention of when not to use it. The helpful auth note is about prerequisites, not usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_user_by_usernameA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the bar for transparency is lower. The description adds valuable context by specifying the exact return structure (fields and nested public_metrics), providing an example, and noting the auth requirement (X_BEARER_TOKEN). It does not mention error conditions or rate limits, but for a simple read-only lookup with good annotations, this is reasonably transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose. It includes the return shape, an example, and auth note in just a few lines with no filler. Every sentence contributes useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple lookup tool with 2 params and no output schema, the description is fairly complete: it explains the input format, return fields, and auth. However, it does not clarify how this tool differs from sibling Twitter tools (e.g., whether 'twitter_user' uses an ID, or 'twitter_users_by_usernames' handles multiple accounts), which could lead to agent confusion in a large tool list.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and both parameters have descriptions in the schema. The description's 'without the @' and example are already covered by the schema's param description ('Handle without the @ (e.g. NBA, AFL, wojespn)'). The description adds no new meaning for the parameters, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource: 'One account's public profile by @handle'. It clearly indicates this tool fetches a single user's profile. However, it does not explicitly distinguish itself from sibling tools like 'twitter_user' (likely by ID) or 'twitter_users_by_usernames' (plural), so it lacks explicit sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you have a @handle for a single account, but provides no explicit when-to-use vs alternatives, no exclusions, and no mention of when to prefer 'twitter_users_by_usernames' for multiple accounts or 'twitter_user' for ID-based lookups. It gives a usage example and auth note, but no strategic guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wta_playerA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, and the description adds useful behavior beyond those: the exact return fields, a concrete example, and the auth requirement. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is reasonably concise but repeats the field list twice ('{id, ...}' and 'Returns: {id, ...}') which is redundant. The example and auth note are useful, but the duplication could be trimmed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-player lookup with one parameter and no output schema, the description provides sufficient information: return shape, source of the ID, an example, and auth requirements. It does not discuss error cases, but that is not critical for this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a detailed description of playerId including source and path requirement. The description repeats the source but adds a concrete example value, providing minor extra value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this tool retrieves a single WTA player by ID and lists the exact fields returned. It distinguishes itself from sibling tools like wta_players (plural) by noting the ID comes from those lookups.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on where the playerId comes from (wta_players/wta_rankings) and confirms no authentication is needed. It implies this is the right tool when you already have a player ID, though it does not explicitly state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wta_player_matchesA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds 'Auth: none needed,' a concrete example call, and the exact return structure, which are useful behavioral details beyond the annotation metadata without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, but it is redundant: the first line presents the return structure, then the 'Returns:' section repeats it with additional fields. The example and auth note are useful, but the redundancy makes it less concise than ideal.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides the return structure, an example, and auth requirements, covering the essential information. It does not mention ordering, pagination, or not-found behavior, but for a simple single-param read-only tool with strong annotations, it is largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage for playerId, including its source (wta_players[].id) and URL path relevance. The description's example ({"playerId": 320760}) adds a concrete illustration but does not introduce new semantic meaning beyond what the schema already documents.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'One player's match history' and 'The per-tournament results/log for a player,' specifying both the resource and scope. It distinguishes this tool from siblings like wta_player (likely profile) and wta_tournament_matches (tournament-centric) by focusing on a single player's matches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for retrieving a player's match history, which gives context for when to use it, but it does not explicitly mention alternatives or exclusions. No guidance on when not to use it versus wta_player or other related tools is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_team_matchupsA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable context by warning that the return shape is unverified from vendor docs and by noting the authentication requirement via YAHOO_CLIENT_ID, YAHOO_CLIENT_SECRET, or YAHOO_REFRESH_TOKEN.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a purpose line, return shape, caveat, example, and auth note. It is longer than average, but the unverified-shape warning and authentication details earn their place. The purpose is front-loaded, and the caveat is important.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description compensates by providing a vendor-documented return shape, even with an explicit caveat that it is approximate. It also includes an example and auth instructions, making the tool sufficiently understood for a simple one-parameter call.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear parameter descriptions. The description adds a concrete example teamKey format ('449.l.12345.t.3') beyond the schema, which helps an agent construct valid calls. The format parameter is also documented as 'Leave as json.'

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource: a team's full season of matchups, including opponents, results, and weekly scores. It implicitly distinguishes itself from sibling tools like yahoo_team_roster and yahoo_team_stats by focusing on matchups, but it lacks an explicit verb like 'retrieves' or 'returns'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied: use this when you need a team's season-wide matchup schedule and results. However, it does not explicitly state when to prefer this over alternatives such as yahoo_team_stats or yahoo_league_scoreboard, and provides no exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_teams_listA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the description does not need to repeat that. It adds useful context by stating 'Auth: none needed' and providing the return structure, which goes beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, covering purpose, scope, return shape, and auth in just two short sections. Every sentence earns its place with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool, the description is complete: the schema documents pagination, annotations cover safety, and the description provides return shape and auth. No additional context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes both parameters (page and pageSize) with defaults and descriptions at 100% coverage. The description adds no extra parameter semantics beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'List teams' with a specific scope (150 incl. AFL men, AFLW, state leagues, historical), which distinguishes it from related team tools like afl_teams_idmap or afl_clubs_list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives such as afl_teams_idmap or afl_clubs_list. The description only lists what the tool does and auth requirements, not when to select it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_basketball_standingsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds a caveat that the return shape is from vendor docs and unverified, plus notes the auth requirement. Since annotations already declare read-only and idempotent hints, this description builds on them by adding a critical data-quality warning without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately sized and front-loaded with the main purpose. The example, caveat, and auth note each serve a purpose, though the return shape snippet adds some verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only standings tool, the description covers purpose, parameters, auth, and return shape with a caveat. It does not document pagination or precise response behavior, but the annotations and simple nature make this adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover all three parameters (team, league, season) with types and examples. The description provides a concrete example of league and season values but adds little semantic value beyond what the schema already offers.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Describes the tool as returning basketball standings for a league and season, which is a specific verb+resource. The basketball scope clearly distinguishes it from other standings tools, and the return shape example further clarifies its function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to choose this over sibling standings tools like balldontlie_nba_standings or apisports_football_standings. The description implies usage for basketball data from API-Sports but lacks exclusions or alternative recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_football_standingsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only and idempotent behavior. The description adds meaningful context by revealing the unverified return shape, explaining the double nesting of tables, and warning that field names should be treated as approximate. This goes beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a brief opening, a compact return-shape block, and clear notes. It is somewhat lengthy due to the detailed shape, but every section serves a purpose, and the caveat is valuable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description thoroughly documents the return structure, including nested arrays and potential grouping. It also covers required parameters, an example, and auth requirements, making it fairly complete for a read-only standings tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema fully describes league, season, and team parameters. The description provides an example and repeats requiredness but doesn't add substantive new meaning beyond the schema's existing descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'League table' clearly identifies the resource and implies a read operation for football standings. It specifies required parameters and provides an example, but it doesn't use a verb like 'get' and doesn't explicitly differentiate from sibling standings tools such as pl_standings or laliga_standing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states that both 'league' and 'season' are required, gives a concrete example, and mentions the need for an API key, providing clear usage context. However, it does not explicitly describe when to use this tool over alternatives or when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apitennis_fixturesA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly, openWorld, and idempotent annotations, the description discloses that the output shape is from vendor documentation and has not been verified against a live response, urging caution. It also mentions the authentication requirement. These are valuable behavioral details not present in annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a clear one-sentence purpose, followed by the return shape, a critical caveat, an example, and auth note. Each section earns its place, though the return shape block adds length. It is well-structured and information-dense without being rambling.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of an output schema, the description provides a detailed (if unverified) return shape, which is essential for agents. It includes an example call and auth requirements. It does not explain optional filter parameters, but the schema covers those. The description is reasonably complete for a read-only data fetch tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes all parameters with 100% coverage, including formats and defaults. The description adds only a usage example that mirrors the schema. Since schema coverage is high, the description's added semantics are minimal, aligning with the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: retrieving matches in a date range with scores and set-by-set details once played. It uses a specific verb and resource, making the purpose clear. However, it does not explicitly differentiate from sibling tools like apitennis_events or apitennis_livescore, 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: for matches within a specific date range. It includes an example showing a one-day query. There are no explicit exclusions or alternative tool recommendations, but the context is sufficient for an agent to infer usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apitennis_livescoreA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable caveats: the return shape is from vendor docs and unverified, and authentication requires the user's own API key. These go beyond the structured annotations and build trust.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a brief purpose statement, return shape example, a necessary caveat, and auth note. Every sentence is purposeful, though slightly long due to the safety note. It earns a 4, not 5, due to the extra caveat length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description compensates by providing an approximate return structure and explicitly warning it may be inaccurate. It also includes auth requirements and a usage example. This covers the core context without over-explaining.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds an example showing the default method, but does not provide further meaning beyond the schema's 'Leave as-is' and 'Restrict to one event type' for the two parameters. No additional semantic depth.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides live scores for matches in progress, using the specific verb 'with live scores' and resource 'matches in progress right now'. It does not explicitly differentiate from sibling tools like apitennis_fixtures, but the phrase 'in progress right now' establishes the live-match scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when the agent needs current live scores for in-progress matches, giving clear context. It does not provide explicit exclusions or name alternatives, so it falls short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• balldontlie_epl_teamsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnly/idempotent/openWorld hints. The description adds a significant caveat: the return shape is from vendor docs and unverified, urging the agent to inspect the actual payload. It also discloses the auth key requirement, going beyond the structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is structured with clear Returns/NOTE/Example/Auth sections; each part earns its place. Slightly verbose, but the note is valuable and the organization aids scanning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given one optional parameter and no output schema, the description provides the expected return shape, an example, auth instructions, and a warning about unverified data. It is complete for a simple tool, with the caveat itself acting as a transparency feature.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single `season` parameter is already fully described in the schema with 100% coverage. The description adds an example value (2023) but no deeper semantics beyond what the schema provides, matching the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Premier League clubs for a season'—clear resource and scope, though it lacks an explicit verb like 'list' or 'get'. It doesn't explicitly distinguish from sibling pl_* team tools, but the return shape and provider reference differentiate it implicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Mentions 'The keyless official premierleague provider is deeper for the EPL'—giving a comparative cue about an alternative. However, it doesn't explicitly state when to choose this tool over siblings or when to prefer the alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_popular_market_linksA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish read-only, open-world, and idempotent behavior. The description adds useful context: 'Auth: none needed' and the return shape. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, with three short lines: a clear one-line purpose, a return format line, and an auth line. Every sentence contributes value, and the structure is well-organized.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple zero-parameter tool, the description is quite complete. It provides the return structure and auth requirement, compensating for the lack of an output schema. It could add more on field meanings or potential errors, but overall it's adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it doesn't, which is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (popular market quick-links) and its purpose (navigation), with examples like specials and featured competitions. It distinguishes from siblings by specifying 'popular market quick-links', though it lacks an explicit verb like 'retrieve' or 'list'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for navigation via quick-links but provides no explicit guidance on when to use this tool versus alternatives or any exclusions. 'For navigation' gives context but is not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfbd_recruitingA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description adds valuable context: the response shape is unverified/approximate and the tool requires a CFBD_API_KEY. This discloses reliability and auth needs that annotations do not cover, though it doesn't discuss pagination or result limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections: purpose, return shape, unverified caveat, example, and auth. Each section serves a purpose, even though the return field list makes it longer than necessary. The first sentence immediately states the core purpose, so it is effectively front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 listing the return fields and adding a reliability caveat. The example and auth note round out the picture. However, it doesn't clarify behavior when no filters are provided (e.g., returns all recruiting classes), which is a minor gap for a tool with all optional parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers all four parameters with clear descriptions (e.g., 'Committed school.', 'Recruiting class year.'). The description only adds an example call, which is illustrative but doesn't deepen parameter understanding beyond schema descriptions. Baseline 3 is appropriate given 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource ('Recruiting classes') and the specific data returned (individual commits with stars, ratings, positions). This distinguishes it from sibling CFBD tools like cfbd_games, cfbd_rankings, and cfbd_teams, which cover different data domains.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a usage example ({"year": 2024}) and notes auth requirements, which gives context for when to call. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusions, so it falls short of full selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfbd_teamsA
  3.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (read-only, open-world, idempotent), the description discloses the exact return shape, notes that the shape is unverified and may be approximate, and clearly states the authentication requirement (CFBD_API_KEY). This adds substantial behavioral context that the annotations do not cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with distinct sections for the resource, return shape, a critical caveat about unverified data, a usage example, and authentication. Every sentence earns its place without unnecessary fluff, making it both concise and informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 providing a detailed return shape, an example, and auth requirements. However, it does not explicitly state that omitting parameters returns all teams or enumerate any pagination/limits, which would have made it fully complete for a list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and both parameters have descriptions, so the baseline is 3. The description adds an example of using the 'conference' parameter ({"conference": "SEC"}) and notes that year affects conference membership, which adds practical value beyond the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'FBS/FCS programmes' with details on conference, venue, and colours, making it distinct from sibling tools like cfbd_games or cfbd_rankings. However, it lacks an explicit verb (e.g., 'list' or 'get') and does not directly contrast itself with alternatives, 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.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an example of filtering by conference but does not explicitly state when to use this tool vs alternatives such as cfbd_team_season_stats or cfbd_advanced_box_score. There is no guidance on when not to use it or which specific use cases it serves beyond the implicit 'retrieve team info'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfbd_team_season_statsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only/idempotent behavior, so the description adds valuable context beyond them: the response is in long format, the shape is from unverified vendor docs, auth requires a key, and users should inspect the actual payload. These warnings help set expectations about reliability.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with labeled sections (Returns, Example, Auth) and a warning note. It is slightly long due to multiple caveats, but each section earns its place and the key facts are front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 format, which it does via the shape example and the long-format clarification. The auth requirement, example, and reliability caveat round out the context needed for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for all three parameters (year, team, conference). The description adds an example call ({'year': 2024}) but does not elaborate on parameter semantics beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Season totals per team across every tracked stat category,' which is a specific verb+resource combination. It also highlights the long-format return shape, distinguishing it from typical per-team aggregation tools and many siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied through the example call and mention of optional filters (team, conference), but there is no explicit guidance about when to use this tool versus sibling tools like cfbd_games or cfbd_rankings. No exclusions or alternatives are named.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketaustralia_fixturesA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and open-world hints. The description adds 'Auth: none needed' and the response envelope including responseError, which are genuinely useful beyond the annotations. No contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: a clear purpose line, a filter note, a return shape, and an auth note. The field list in the Returns line is somewhat dense but serves as a substitute for an output schema, so it earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 8 optional params, no output schema, and robust annotations, the description plus full schema coverage gives a complete picture of a read-only fixtures list. Minor gaps remain about default time ranges and pagination/limit behavior, but the overall context is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All 8 parameters have schema descriptions (100% coverage), so the baseline is 3. The description's filter mention does not add parameter-specific detail beyond what the schema already provides, so it earns the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies the tool as 'Match list (the /matches feed)' and enumerates the contained fields (teams, venue, competition, status, toss, result), making the resource and scope clear. It does not explicitly contrast with siblings like scorecard or standings, but the feed-based framing is distinct enough.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states 'Filter by competition, completed/live, etc.,' giving clear context for when to use the tool and how to narrow results. It does not provide explicit alternatives or exclusions, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketdata_player_infoA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the readOnlyHint/openWorldHint annotations by explicitly warning that the return shape is from vendor docs and unverified, advising the agent to inspect actual payloads. It also discloses the long-format `stats` structure and the need for a CRICKETDATA_API_KEY, adding valuable behavioral context without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is structured with clear sections: purpose, return shape, caveat, example, and auth. While it is somewhat lengthy, every section carries necessary information—especially the unverified shape warning—and there is minimal redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 fully documenting the return shape, the long-format nuance, and the authentication requirement. It is reasonably complete for a single-parameter tool, though it does not cover error conditions or missing-data behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage for the single `id` parameter, including provenance ('from cricketdata_players'). The description's example merely repeats the schema structure and adds no semantic depth beyond what is already documented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'One player's profile and career batting/bowling statistics,' which identifies the specific resource (player) and scope (single player). This distinguishes it from sibling tools like cricketdata_players (likely a list) and cricketdata_scorecard, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you have a player ID and need profile/career stats, and the example shows the input. However, it does not explicitly state when to prefer this tool over alternatives, nor does it provide exclusions or alternative tool references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_hist_dfs_event_listA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it requires a user-provided DATAGOLF_KEY and specifies the top-level array return structure. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence purpose, a return shape, and an auth note. Every sentence earns its place with no fluff or redundancy. It is easy to parse and front-loaded with the key purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description provides a return array example, which helps. However, it is inconsistent: it mentions 'points data' but the return example lacks any points field, and the fields are hardcoded as 'dk_salaries' even though the tool supports multiple sites. This incomplete/misleading return info leaves gaps for a simple list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage of both parameters (site and file_format) with descriptions and enums. The description adds no additional parameter semantics beyond saying 'for a site', which is already in the schema. Baseline of 3 is appropriate since schema carries the load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'List of historical events with DFS salary/ownership/points data for a site.' The verb 'List' plus the specific resource (historical events with DFS data) is precise. It distinguishes itself from sibling tools like datagolf_hist_event_list by explicitly mentioning DFS salary/ownership/points data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context (historical DFS events) but gives no explicit guidance on when to use this tool over alternatives, nor any exclusions or when-not scenarios. The auth note is a prerequisite, not usage guidance. The 'site' parameter is mentioned but not framed as a choice criterion among similar tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• footballdataorg_competitionA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the operation as read-only, idempotent, and open-world. The description adds that an API key is required (403 without it) and candidly notes that the return shape is from vendor docs and unverified, which is a valuable caveat for the agent. No contradiction with annotations; it supplements them with auth and data reliability context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately sized with clear sections: summary, return shape, caveat, example, and auth. Each part adds value, though the note about vendor docs could be considered slightly verbose. Overall it is well-structured and front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides the expected JSON shape and highlights that it is unverified, which is important context. It covers auth, an example, and the purpose. Given the tool's simplicity and strong annotations, the description is sufficiently complete for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes the single parameter with valid competition codes and a note about URL path integration (100% coverage). The description adds a concrete example (`PL` for Premier League) but no additional semantic meaning beyond the schema. The example helps with format but does not elevate semantics significantly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'One competition with its current season and available seasons,' identifying the resource and scope. The singular form distinguishes it from the sibling `footballdataorg_competitions`. The return shape and example reinforce the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for fetching a single competition, but it does not explicitly state when to use this versus the plural `footballdataorg_competitions` or other competition-specific tools. The example shows a typical invocation and the auth note provides a prerequisite, but no explicit when-not guidance is given. Usage is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• highlightly_basketball_highlightsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable caveats beyond annotations: the return shape is 'from vendor docs' and unverified, advising to 'inspect the actual payload before relying on a field name'. It also discloses the auth requirement (HIGHLIGHTLY_API_KEY), which is not in 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized: a one-sentence purpose, a return shape, a caveat about shape reliability, an example, and auth note. Each part earns its place, and the most critical information (purpose) is front-loaded. The caveat is slightly verbose but necessary for transparency.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a return shape (even if marked approximate), an example call, and auth requirements. Given the tool's simplicity and the schema covering all parameters, this is reasonably complete. It could mention pagination behavior, but the return shape includes 'pagination', and the openWorldHint suggests the response may vary.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all four parameters (date, limit, matchId, leagueId), giving 100% coverage. The description adds an example for 'date' but does not explain the semantics of limit, matchId, or leagueId beyond what the schema already states. This meets the baseline but doesn't exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Basketball highlight clips (NBA, EuroLeague and others)', specifying both the resource (highlight clips) and the domain (basketball). This distinguishes it from sibling tools for other sports like soccer, NFL, baseball, and hockey, which share the 'highlightly_' prefix.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an example using the 'date' parameter and notes the need for an API key, implying when the tool might be used. However, it doesn't explicitly state when to prefer this over sibling tools or how to choose between parameters like matchId versus leagueId. Usage context is implied but not fully elaborated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• highlightly_soccer_matchesA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds valuable behavioral context: the return shape is unverified from vendor docs, the score is nested under state, auth via HIGHLIGHTLY_API_KEY is required, and the actual payload should be inspected. This goes beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is somewhat lengthy but each section earns its place: purpose, return shape with caveat, example, and auth note. The structure is front-loaded with the core purpose and the caveat about unverified shape is important. It could be slightly tighter but is well-organized.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description provides an approximate return shape, which is critical. It also includes auth requirements and an example. The mention that the shape is unverified and should be inspected is excellent for setting expectations. This is complete for a simple list-like tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the description does not need to define parameters. It adds a brief example of using the date parameter, but does not provide additional semantics for limit, season, or leagueId. This is sufficient given the schema already documents all parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (football matches) and the intended purpose (finding matchId for highlight lookup). It distinguishes itself from sibling tools like highlightly_soccer_highlights by stating the matchId need. However, it lacks an explicit verb like 'get' or 'list', making the action somewhat implicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use this tool to obtain a matchId before performing a highlight lookup. This distinguishes it from the highlighted sibling tool. It does not explicitly state when not to use or name alternative tools, but the context is clear for a straightforward match lookup.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• isportsapi_basketball_scheduleA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, open-world, and idempotent hints. The description adds valuable transparency beyond annotations: it warns that the return shape is from vendor docs and unverified, and it explicitly mentions the required ISPORTS_API_KEY auth. No contradictions 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the core purpose, followed by return shape, unverified note, example, and auth. Each component earns its place, though it's slightly longer than necessary for such a simple tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read-only tool with no output schema, the description provides a return shape (with caveat), an example, and auth context. It doesn't explain behavior when both parameters are omitted, but the openWorldHint annotation partially covers that gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents both parameters with 100% coverage, so the description carries minimal burden. It adds an example date value ('2024-01-15') but no additional semantics beyond what the schema provides, matching the baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (basketball fixtures and results) and scope (by date), though it lacks an explicit verb like 'Get' or 'List.' It is unambiguous but does not explicitly distinguish this from sibling basketball schedule tools, so it doesn't earn a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by showing an example for a day's games and noting the optional leagueId restriction. However, it does not mention when to prefer this tool over alternatives or state exclusions, so it misses the explicit guidance required for a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• isportsapi_football_scheduleA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnly, openWorld, and idempotent hints, lowering the transparency burden. The description adds valuable behavioral context: it explicitly warns the return shape is from vendor docs and unverified, clarifies matchTime is a UNIX timestamp, and notes that a provider API key is required. These details go beyond the annotations, though it doesn't discuss rate limits, pagination, or behavior when both params are omitted.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a clear summary, then includes structured sections for return shape, a caveat, an example, and auth. Each section earns its place: the caveat is important for trust, the example clarifies usage, and the auth note is essential. It's slightly verbose due to the cautionary note, but not bloated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 giving the full return shape and flagging it as unverified, which is crucial for an agent. It also provides an example and auth context. Missing details include the default behavior when no date is supplied, pagination, timezone handling, and sort order, but for a simple date-based list tool, the description is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both date ('YYYY-MM-DD.') and leagueId ('Restrict to one competition.'). The description adds an example for date and implies usage, but it doesn't provide additional meaning for leagueId beyond the schema. Since the schema already carries the parameter semantics, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Football fixtures and results by date' which clearly identifies the verb (returns), resource (football fixtures/results), and scope (by date). This distinguishes it from siblings like isportsapi_football_live (live scores) and isportsapi_football_competitions (leagues), making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete example ({"date": "2024-08-17"}) and mentions an optional leagueId in the schema, implying usage for date-based fixture/result lookup. However, there is no explicit guidance on when to choose this over alternatives (e.g., live vs. scheduled results, or other providers), nor does it state exclusions or prerequisites (e.g., required date format is in schema, not fully elaborated).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• jolpicaf1_driver_standingsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already label it read-only, open-world, and idempotent. The description adds useful context like auth requirements and the return structure, but also mentions 'after a specific round' which is not reflected in the input schema, potentially misleading. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear purpose statement, return schema, example, and auth note. The return schema is lengthy but necessary to highlight the 'extra StandingsLists layer'.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 compensates by providing the full return structure, an example, and auth info. However, the 'specific round' mention is unexplained and the limit parameter is not described behaviorally.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 an example using season and format but does not add further meaning to the limit parameter or clarify the round discrepancy.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this tool returns 'Drivers' championship standings' and explicitly distinguishes from sibling tools like constructor standings by using 'Drivers''. The purpose is specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear context on when to use: for driver standings after a season or round. However, it does not explicitly mention alternatives or when not to use this tool, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• jolpicaf1_pitstopsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a safe, read-only, idempotent operation. The description adds valuable context beyond annotations: it clarifies the semantics of 'duration' vs 'time', states that auth is not needed, and shows the response structure. No contradictions 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: definition, return shape, field clarification, example, and auth note. Each line earns its place, and the return shape is especially useful given the lack of an output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with well-documented parameters and helpful annotations, the description is complete: it provides the return structure, an example call, and permission requirements. It sufficiently compensates for the missing output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all parameters. The description adds a concrete example of parameter values, but does not add significant semantic detail beyond what the schema already provides. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as retrieving pit stops for a race, listing the key fields (lap, time, duration). It distinguishes itself from other jolpicaf1 tools by focusing specifically on pit stop data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through its definition and provides an example invocation, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. The context is clear but not fully explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• jolpicaf1_qualifyingA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is established. The description adds value beyond annotations by detailing the exact return structure (MRData:RaceTable:...) and the behavior that Q2/Q3 are absent for drivers eliminated earlier. This is useful behavioral context not covered by 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with purpose. The first sentence states what the tool does, followed by the return shape, an example, and an auth note. Each line adds value. It is slightly longer than necessary due to the inline return schema, but this is informative rather than redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the moderate complexity, the description covers the key aspects: purpose, return format, example, auth requirement, and special case for Q2/Q3 omission. The schema covers parameter details, and annotations cover safety. The only missing piece is explicit differentiation from sibling tools, but the purpose line largely handles that. Overall it is sufficiently complete for an agent to invoke successfully.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with all four parameters (season, round, limit, format) having descriptions. The description's example shows the expected usage of season, round, and format, which reinforces the schema but does not add new semantic information. Since the schema already does the heavy lifting, a baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific statement: 'Qualifying results with Q1/Q2/Q3 times per driver.' This clearly identifies the resource (qualifying results) and the content per driver (Q1/Q2/Q3 times). It distinguishes itself from sibling tools like jolpicaf1_results (race results) and jolpicaf1_sprint (sprint results) by focusing narrowly on qualifying.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete example ('2024 round 1 qualifying') and notes that 'Auth: none needed,' which gives practical usage context. However, it does not explicitly state when to use this tool versus alternatives like jolpicaf1_results or jolpicaf1_sprint. The usage guidance is implied by the name and description rather than spelled out.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• jolpicaf1_resultsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool read-only, idempotent, and open-world. The description adds useful behavioral context beyond annotations: 'Auth: none needed' and 'all values are STRINGS'. It does not mention rate limits or pagination, but the annotations cover the safety profile, so this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a concise summary, followed by a detailed return structure and a brief example. The return structure is somewhat verbose but necessary to convey the nested output format. Overall, it is efficient and well-organized, though it could be slightly more compact.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The detailed return structure compensates for the absence of an output schema, and the example clarifies the required parameters. However, it does not explain the meaning of specific result fields (e.g., status, positionText) or handle edge cases like invalid season/round values. For a simple read-only tool, this is mostly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents all four parameters with descriptions at 100% coverage. The description only repeats an example with season and round, adding little parameter-level meaning beyond what the schema already provides. The baseline of 3 applies because the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning race results with specific fields (finishing order, grid, laps, time/status, points, and fastest lap). It distinguishes from sibling tools like jolpicaf1_qualifying and jolpicaf1_sprint by focusing on race results rather than qualifying or sprint sessions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly compare this tool to alternatives or state when to use it over sibling tools like jolpicaf1_laps or jolpicaf1_qualifying. It provides an example (2024 round 1) and notes that auth is not needed, giving some context, but lacks explicit 'use this when...' guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_candlesticks_batchA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description need not repeat those. It adds value by stating 'Auth: none needed' and providing the exact response shape (markets, candlesticks fields), which goes beyond the structured metadata. No contradictions 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: first sentence states the core purpose, second gives the return structure, third covers auth and a cross-reference. No wasted words, though the final 'Also answers this: polymarket_price_history' is ambiguous and slightly hurts clarity, preventing a 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides the return shape and fields, which is useful. It also notes auth requirements. Combined with the rich annotations and full schema coverage, the tool is sufficiently described for an agent to invoke it. Minor gaps: no mention of pagination or potential response size, but these are less critical given the batch nature and no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and each parameter has its own description. The description only adds 'pass the tickers as a list', which is already implied by the 'Market ticker(s)' schema description. It does not provide additional meaning about period_interval, start_ts, or end_ts beyond the schema, so the baseline of 3 is appropriate both because the schema covers everything and the description contributes little extra.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides OHLC candlesticks for 'MANY markets in one call', which distinguishes it from the single-market sibling kalshi_candlesticks. It also specifies the resource (markets, candlesticks) and the verb implied (get/fetch). The return format is shown, further clarifying what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use for batch/multi-market requests via 'MANY markets' and notes it also answers polymarket_price_history, offering a hint about overlap with that sibling. However, it lacks explicit when-to-use vs. alternatives, no exclusions, and no guidance on when to prefer the single-market tool. The mention of polymarket_price_history is cryptic rather than a clear routing instruction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• laliga_playerA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond annotations by disclosing authentication requirements (works without a key, LALIGA_SUBSCRIPTION_KEY unlocks more) and explicitly showing the return structure. Annotations already declare read-only, open-world, and idempotent behavior, and the description does not contradict them. It could mention error cases or rate limits, but the provided context is sufficient for a simple read operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured with clear sections for purpose, return value, and auth. There is slight redundancy because the first sentence lists fields that are repeated in the Returns block, but it remains efficient and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only profile lookup, the description provides a clear return contract and auth notes. Gaps include unspecified error behavior and what exact data 'LALIGA_SUBSCRIPTION_KEY unlocks more' refers to, but these are minor for typical agent use. The lack of an output schema is partially compensated by the explicit Returns field list.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the slug parameter, including where to obtain it and that it's part of the URL path. The description adds minimal extra meaning beyond emphasizing 'by SLUG', so it meets the baseline but does not elevate it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as fetching a single player profile by slug and lists the specific fields returned (name, birth date, country, team, squad, roles). This distinguishes it from sibling tools like laliga_player_stats and laliga_squad, which serve different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when you have a player slug and need profile information, but it does not explicitly state when to use it over alternatives like laliga_player_stats or laliga_squad. The schema hints at a workflow (slug from laliga_players_stats/laliga_squad), but the description itself lacks explicit when-to-use/when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• laliga_standingA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses the exact return shape, the fact that it returns 20 entries, and the authentication behavior. It also provides a concrete example of the input. This adds meaningful behavioral context such as what data is included and that no key is required, though it does not cover error handling or pagination (not needed for a single-table tool).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is structured with labeled sections (Returns, Example, Auth) and is information-dense without being overly verbose. The main purpose is stated in the first sentence, and all subsequent details are relevant. It is slightly long but each part earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 providing a detailed return structure, an example input, and auth information. The tool is simple (one parameter, no enums), and the description covers the key aspects needed to invoke it successfully. It could mention how to find valid slugs (e.g., referring to laliga_subscriptions), but this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage for the single parameter, including an example slug and explanation that it is part of the URL path. The description's example mirrors the schema's example without adding new semantic detail. Baseline of 3 is appropriate since the schema carries the full weight.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Full league table for a season' with a specific resource (La Liga standings) and enumerates the exact fields returned (played, won, drawn, etc.). The example and return structure make the tool's function unambiguous and distinguish it from other standings tools by confirming it is the complete table for a season.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context: to retrieve a full league table for a given season, with an example slug. However, it does not explicitly state when to prefer this tool over alternatives (e.g., pl_standings, seriea_standings) or mention any exclusions. The auth note provides some operational context but not comparative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lichess_leaderboardA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, establishing a safe read operation. The description adds valuable context: the exact return format ({users:[...]}) and explicitly states 'Auth: none needed.' This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-line purpose, a return format snippet, a concrete example, and an auth note. Every sentence delivers useful information with no fluff, making it easy to scan and understand.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter tool with complete schema descriptions and strong annotations, the description is fully adequate. It includes the return shape, an example, and auth requirements, so an agent has all necessary information to call it correctly without needing an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers 100% of parameters with descriptions and defaults for both 'perf' and 'count', so the description doesn't need to repeat them. The example re-illustrates the parameters but doesn't add new semantic meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns top-rated players for a specific time control or variant, using a specific verb ('Top-rated players') and the resource (lichess leaderboard). It distinguishes from the sibling 'lichess_leaderboards_all' by focusing on a single perf, though it doesn't explicitly name the alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through the example 'Top 10 blitz players' with count and perf, indicating how to request a specific leaderboard. However, it doesn't provide explicit guidance on when to use this tool versus siblings like lichess_leaderboards_all, nor when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_jobsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish read-only, open-world, and idempotent semantics. The description adds the exact return shape 'roster:[{person, jobType, job}]' and an explicit auth note ('Auth: none needed'), which goes beyond what annotations provide. There is no contradiction with the readOnlyHint, so it is consistent and informative.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: one sentence for the main purpose, one line for the return shape, one line for auth. Every sentence serves a purpose, and there is no filler. The structure is front-loaded with the core behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with strong annotations and full schema coverage, the description covers the essential aspects: what is returned, examples of required parameter values, and authentication requirements. It omits details like default season behavior or pagination, but those are not critical for this kind of tool and are partially covered by the schema default.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all three parameters with descriptions (100% coverage). The description enriches the jobType parameter by providing concrete valid examples (UMPR, SCORER, DATACASTER, BROADCASTER, COACH), which is helpful for an agent selecting the correct code without querying mlb_meta. Still, it does not fully replace the referenced metadata lookup.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the resource: people holding a job type for a season, with examples of job types like UMPR and SCORER. It differentiates itself from dedicated endpoints like mlb_umpires by offering a generic jobType parameter, but it does not explicitly name those siblings. Thus it is clear but not fully distinguished.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on what it returns and example jobType values, implying this is a general way to fetch various job types. However, it gives no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as the dedicated mlb_umpires or mlb_datacasters endpoints.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_sportsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that no authentication is needed, which is useful behavioral context beyond the annotations. It also specifies the return shape and provides meaningful interpretation of the sportId values, adding transparency. With readOnlyHint and idempotentHint already present, the description adds additional value without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, using only three short sentences. It front-loads the core purpose, then covers the return format and authentication, with no redundant or filler content. Every sentence contributes valuable information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only catalogue tool with one optional parameter, the description is quite complete. It covers purpose, parameter meaning, return structure, and auth. While it omits potential edge cases like empty results or pagination, these are unlikely to be significant for such a tool, and the annotations plus return format provide sufficient context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only says the parameter 'Filter to one sport', but the description adds crucial semantic detail by explaining that 1 means MLB and other values correspond to MiLB, college, or international levels. This goes beyond the schema's minimal description, significantly improving parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a sport catalogue and a sportId lookup, with the specific mapping for MLB. It distinguishes itself from other MLB tools by focusing on the sport-level lookup rather than teams, leagues, or divisions, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied through the phrase 'sportId lookup' and the description of sport IDs, making it clear the tool is for resolving sport identifiers. However, there is no explicit statement about when to use this tool versus alternatives or any exclusions, leaving the guidance somewhat implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• motogp_session_classificationA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds valuable context: no authentication is needed, and it details the response structure (classification array with rider, team, time/gap, etc.), which is especially helpful given the absence of an output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately concise and front-loaded: first line states purpose, then return structure, then example/auth. The 'Example: A race result' section is slightly ambiguous (it appears to be an input example, not an output example), but overall the text is efficient and to the point.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with one required parameter, the description is largely complete. It provides a detailed return structure, compensating for the missing output schema. However, the 'records' and 'file' fields in the return object are unexplained, and there is no guidance on invalid sessionUuid behavior, so it stops short of full completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; it only includes an example of sessionUuid in the example section, while the optional 'test' parameter is explained only in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: returns the result of one session with finishing order, rider, team, bike, time/gap, and points. It distinguishes from sibling tools such as motogp_sessions (which lists sessions) and motogp_standings (which provides standings) by focusing specifically on session classification.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: use this tool when you need the classification/result for a single session. However, the description does not explicitly mention alternatives, exclusions, or how to obtain a sessionUuid (though the schema notes it comes from motogp_sessions).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_scheduleA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, setting a safe read operation baseline. The description adds valuable context by detailing the exact return fields, stating 'Auth: none needed', and providing an example. It does not mention pagination or limits, but it is reasonably transparent for a simple schedule endpoint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than a minimal one-liner, but the structure is well-organized: a summary sentence, a return-type block, an example, and an auth note. The detailed return structure is justified since no output schema exists, and the core purpose is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 showing the complete return shape (including nested team objects), providing a concrete example, and stating authentication requirements. It covers the parameter options and the scope of data ('every match for one season'). Minor gaps like sort order or pagination are not critical for this type of endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both 'year' and 'seasonType' fully described, including the year-to-season mapping and the enum values. The description's example repeats this same information ('2025 = NBL26', 'seasonType=all') without adding new parameter meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'every match for one season' and enumerates the fields returned, distinguishing it from season-level metadata tools like nbl_seasons or match-outcome tools. However, it lacks an explicit verb like 'list' or 'retrieve', which would make the purpose even more direct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it is for retrieving a full season's schedule and results, with `seasonType=all` for the entire season. The example call further demonstrates the intended usage. It does not explicitly mention alternatives or when not to use it, but the scope is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncaa_rankingsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only and idempotent hints, and the description adds the exact return shape, uppercase key warning, an example, and auth requirement. This gives useful behavioral context beyond the structured fields without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the tool's purpose. Every line contributes value: the summary, return structure note, example, and auth mention—nothing wasted.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description explicitly lists the return object structure. With simple parameters that have defaults and good annotations, the description covers the needed context (purpose, example, auth, key casing) fully for this tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter (poll, sport, division) is already documented. The description adds an example showing valid values and defaults, but it does not provide additional semantics beyond what the schema already supplies, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns poll rankings (AP, coaches, etc.) for a college sport and division, with a concrete example. It does not explicitly name sibling tools like cfbd_rankings or ncaa_standings to differentiate, but the return format note about UPPERCASE keys distinguishes it from standings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the description and example (e.g., for AP football poll), but there is no explicit 'when to use this vs. alternatives' or 'when not to use' guidance. The 'unlike standings' remark is more about key casing than usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncaa_standingsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds valuable behavioral context beyond these. It details the return structure, notes that inner column names vary by sport and contain spaces, and clarifies that all values are strings. It also states that no authentication is needed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the purpose. It packs essential details (return shape, grouping, column variability, auth) into a concise format without redundancy. The example is helpful and placed logically after the return structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Since there is no output schema, the description appropriately compensates by fully specifying the return format and grouping behavior. It covers auth and provides an example. However, it mentions 'page' and 'pages' without explaining pagination semantics, leaving a minor gap for a tool with this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers both parameters with descriptions, achieving 100% coverage. The description adds a concrete example (sport='football', division='fbs') that clarifies valid values and usage. This goes beyond the schema's minimal 'slug' descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: returns conference standings for a college sport and division. It distinguishes from siblings by specifying 'college sport' (NCAA) and providing a detailed return structure grouped by conference. The example for FBS football adds specificity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide any guidance on when to use this tool versus alternatives. While many sibling standings tools exist, there is no mention of selection criteria or exclusions. The example implicitly shows usage, but no explicit guidance is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhl_goalie_leadersA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond the readOnlyHint annotation by detailing the return structure (e.g., {wins:[...], savePctg:[...]}), providing an example call, and noting that no authentication is needed. This gives the agent a clear picture of what the tool returns and any access requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the core purpose. It includes a return structure and example without excessive verbosity. Each section earns its place, though it is somewhat longer than the minimum viable description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity and the presence of a 100% covered schema, annotations, and a detailed return structure in the description, the tool is well-specified. The description compensates for the absence of an output schema by outlining the response fields. It covers purpose, example, and auth, making it complete for a read-only leaderboard tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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's example ({"season_or_current": "current", "limit": 10}) adds a practical usage illustration, but it does not explain parameter semantics beyond what the schema already provides. The schema fully documents each parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'League leaders among goalies — wins, save percentage, goals-against average and shutouts.' It uses a specific verb and resource, and the focus on goalies distinguishes it from sibling tools like nhl_skater_leaders.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: if you need goalie league leaders, use this tool. However, it does not explicitly state when to use it over alternatives (e.g., nhl_skater_leaders) or provide exclusions. The guidance is implied but not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhl_scoresA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations (readOnlyHint, openWorldHint, idempotentHint) already establish safety, and the description adds context beyond them: 'Auth: none needed' and a full return payload layout including gameState, clock, and period fields. This sets realistic expectations for a live read operation without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The purpose is front-loaded in a single sentence, and the auth note and example are compact. The lengthy return-type block is verbose but earns its place because there is no output schema, giving the agent a precise picture of the response structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 fully spelling out the return shape (currentDate, games, teams, scores, clock, period, goals, gameWeek), plus auth and example usage. For a simple one-parameter read-only tool, this is nearly complete; only minor edge behavior (e.g., dates with no games) is left implicit.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully documents the date parameter ('YYYY-MM-DD, or 'now' for today') with 100% coverage, so the description's {'date': 'now'} example merely reinforces the default. The description adds no new semantic meaning beyond what the schema provides, matching the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Live scoreboard' and precisely scopes the tool: every game on a date with current score, clock, and period. This distinguishes it from sibling NHL tools like nhl_schedule and nhl_boxscore, which cover scheduling and single-game details rather than a date-based live scoreboard.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The use case (fetch a date's scoreboard) is clear and supported by the 'Today's scores' example, but the description never explicitly names alternatives or states when not to use this tool. An agent must infer from sibling names (e.g., nhl_schedule, nhl_boxscore) when another tool would be more appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• oddsapiio_leaguesA
  3.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that the response shape is from vendor docs and unverified, which is significant behavioral transparency beyond the readOnly/idempotent hints. It also clearly states the API key requirement, which annotations don't cover. This goes well beyond what the annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with sections for summary, returns, note, example, and auth. It is front-loaded with the core purpose. Some redundancy exists ('NEEDS A KEY' vs 'Auth: needs your own key'), but overall it is concise and every section earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple list tool with 2 parameters and no output schema, the description provides the approximate return shape, an example, and auth guidance. It adequately covers what an agent needs to invoke this tool, though it lacks explicit error handling or edge-case guidance. The unverified-shape caveat adds important context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes both parameters with 100% coverage. The description adds an example ({"sport": "football"}) but doesn't provide additional meaning about the country parameter or value formats beyond what the schema already states. With full schema coverage, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Leagues within a sport' clearly indicates the tool retrieves leagues for a given sport, and the example with {"sport": "football"} clarifies the input. It lacks an explicit verb like 'list' and doesn't differentiate from siblings, but the name and example make the purpose evident.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you need leagues for a sport, supply a sport slug. It doesn't mention alternatives or when not to use it, but it does provide an example and notes the auth requirement as a prerequisite. This is adequate but not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• oddsapiio_oddsA
  3.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly, openWorld, idempotent), the description discloses that the response shape is unverified from vendor docs, that bookmakers are keyed by name rather than a list, and that a personal key is required. This is substantial behavioral context that helps the agent avoid misinterpreting the response.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with clear sections: purpose, return shape, verification note, example, and auth. The vendor-doc disclaimer adds necessary length, but the content is focused and each sentence serves a purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description adequately covers the return shape and auth requirements. It warns about unverified fields, which is critical. However, it lacks guidance on how to obtain the eventId (though the schema references oddsapiio_events) and does not mention potential errors.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for all three parameters (eventId, markets, bookmakers), so the baseline is 3. The description adds no extra parameter semantics beyond showing eventId in the example, which is redundant with the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns odds for one event across indexed bookmakers, with a specific verb and resource. It distinguishes itself from sibling tools by focusing on a single event, though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving odds for a specific event and notes the key requirement, but provides no explicit when-to-use or when-not-to-use guidance compared to alternatives. The example shows the required eventId but no direction on optional filters.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openligadb_teamsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool read-only, idempotent, and open-world, so the description is not required to repeat those. It adds value by stating 'Auth: none needed' and detailing the exact return fields, which goes beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and appropriately front-loaded: one purpose sentence, a return-type line, an example, and an auth note. No filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity (2 parameters, no output schema), the description covers the essential aspects: what it returns, a usage example, and authentication status. The annotations handle safety semantics, so nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides full descriptions for both `league` and `season` (100% coverage), so the baseline is 3. The description reinforces these with a concrete Bundesliga example, but doesn't introduce new semantic information beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the resource: 'The clubs contesting one league season' and specifies the return structure, making it clear this tool retrieves teams for a given league season. It stands apart from sibling tools like openligadb_table or openligadb_matches, though it doesn't use a verb like 'list' or 'get'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is the tool to call when you need the clubs participating in a specific league season, and provides a concrete example. However, it does not explicitly contrast with alternatives or state when not to use it, leaving usage guidance implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pandascore_seriesA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds a valuable caveat that the return shape is from vendor docs and unverified, and notes the authentication requirement. This goes beyond annotations, though it does not disclose pagination 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with brief segments for definition, return shape, caveat, example, and auth. Every sentence serves a purpose and there is no filler. The warning about the unverified shape is essential context, and the example is practical.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple listing tool with no output schema, the description provides the return shape, an example, authentication details, and a reliability caveat. It lacks an explicit statement about behavior when no filter is applied, but the schema defaults and example make the expected behavior fairly clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of parameters, yielding a baseline of 3. The description's concrete example (filter_videogame: 'lol') clarifies the expected slug format, which adds meaningful value beyond the schema's vague 'Title slug'. This justifies a 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly identifies 'Series' as a league's seasonal editions and provides the return shape, making it evident that the tool retrieves series data. However, it lacks an explicit action verb like 'List' or 'Fetch', and does not directly differentiate from sibling pandascore tools (e.g., pandascore_tournaments), so it falls short of a top score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example with filter_videogame implies a usage scenario, but there is no explicit statement about when to use this tool versus alternatives like pandascore_tournaments or pandascore_matches. No when-not-to-use or alternative tool references are provided, leaving usage guidance solely implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_player_basicA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, idempotent, and openWorld hints. The description adds value by stating that no authentication is required and by explicitly listing the response fields. It does not cover error behavior or data freshness, but these are less critical given the annotations and simple nature of the tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two short sections covering what the profile includes, the exact return shape, and auth requirements. Every sentence adds useful information and there is no filler. It is front-loaded with the tool's purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool with one parameter and no output schema, the description is complete: it states the returned object structure and authentication requirements. The annotations cover safety and idempotency. The description gives an agent enough information to select and invoke the tool correctly without needing to infer hidden behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter 'pid' is fully documented in the input schema with type, origin (pl_players), an example, and the fact that it is part of the URL path. Since schema coverage is 100%, the description does not need to add parameter details. The description contributes nothing beyond the schema, matching the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a 'Lightweight player profile' and specifies the fields it returns (name, position, country, currentTeam). It lacks an explicit verb like 'retrieve' but the intent is unambiguous. The word 'Lightweight' subtly distinguishes it from fuller player profile tools, though it does not name any sibling explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for basic profile lookups and states that no auth is needed, which is useful context. However, it provides no explicit guidance on when to use this tool versus alternatives like pl_player or pl_player_info. There are no exclusions or comparisons to sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_playersA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish read-only, idempotent, and open-world behavior. The description adds useful context beyond annotations by specifying pagination, the exact return shape ({pagination, data:[...]}), and the lack of authentication requirements. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is succinct and well-structured, with a one-sentence purpose, a return format, a practical example, and an auth note. Every line serves a clear function, with no redundant wording or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description compensates by revealing the return structure and providing a concrete invocation example. Combined with a fully described input schema, the agent has sufficient context to select and call the tool correctly, including pagination awareness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers 100% of parameters with descriptions, so the baseline is 3. The description only adds a concrete example using cid, sid, and limit, which reinforces schema semantics but does not introduce new meaning or clarify aspects not already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a player directory for a season, with the 'Players index page' phrase adding specificity. It distinctively positions it against sibling tools like pl_players_by_id or pl_squad by implying a listing context, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied through the descriptor and example (listing players for a given season), but the description lacks explicit guidance on when to use this tool versus other player-related tools like pl_players_by_id or pl_squad. No exclusions or alternative recommendations are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_content_callA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint/idempotentHint annotations, the description adds useful behavioral context: no auth needed, returns a JSON object, and guessing an operation name returns an error listing alternatives. It also explains what the assets drive (menus, tiles, etc.). No contradictions with annotations, though the '(no params)' phrase is internally inconsistent with the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured with clear sections for returns and auth. The misleading '(no params)' phrase is extraneous and slightly confusing, but overall the text is efficient and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description at least states the return type (JSON object) and points to the operation catalogue for further context. It does not detail the JSON structure, but for a generic static-content fetcher this is acceptable. The auth requirement and asset purpose round out the picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with each parameter well described. The description adds marginal value by pointing to the catalogue resource for valid operation names, but it does not significantly extend beyond the schema's already detailed parameter explanations.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it fetches PointsBet's static CMS/navigation JSON assets by operation name, distinguishing it from sibling tools that retrieve live sports data. However, the parenthetical '(no params)' is misleading because the schema accepts optional path_params and query_params, which slightly muddies the stated purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly indicates the tool is for static content/navigation assets rather than dynamic data, and directs the user to read pointsbet://content/operations for the operation list. It does not explicitly name alternatives or state when not to use it, but the scope is well implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_racing_futuresA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by specifying 'Auth: none needed' and the exact return format ({events:[{key, name, competitionName, startsAt}]}), which is beyond the annotations. No contradictions found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very brief and front-loaded: main purpose first, then return shape, then auth requirement. Every line is informative with no filler, making it easy to scan and understand.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter, read-only tool with strong annotations, the description covers purpose, output, and auth. It could slightly improve by explicitly stating that it lists all available futures markets, but the current wording is sufficient for most use cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics; the empty input schema is self-explanatory. The description's focus on output structure is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'Racing futures markets' with specific examples (Cup/Carnival outrights) and details the return structure. It distinguishes from sibling tools like pointsbet_racing_race by focusing on long-running markets, but lacks an explicit verb, making it slightly less actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for racing futures markets but provides no explicit when-to-use guidance or alternatives. It does not contrast with sibling tools such as pointsbet_racing_meetings or sportsbet_racing_futures, leaving the agent to infer context from the tool name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• polymarket_price_historyA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint and idempotentHint annotations already present, the description adds valuable context by stating 'Auth: none needed' and specifying the exact return shape '{history:[{t, p}]}' with unix seconds and price 0-1. No annotation contradiction is present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately short, leading with the purpose and providing return shape and auth in three lines. The final line about kalshi_candlesticks is confusing and somewhat undermines the otherwise clear structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only historical price tool with full schema coverage and helpful annotations, the description covers the essentials: purpose, time selection, return format, and auth. It doesn't need to explain return values further since it explicitly provides the return shape, making it complete enough for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already contains detailed descriptions for all five parameters (100% coverage), including the enum values for interval and the alternative relationship between interval and startTs/endTs. The description only reiterates the two query modes, adding little beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Historical price series for one outcome token — by named interval or an explicit ts window,' which clearly identifies the verb (historical price series), resource (one outcome token), and two query modes. This distinguishes it from sibling price tools like polymarket_price and polymarket_spread, which likely serve other purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating both named interval and explicit ts window options, but does not explicitly say when to prefer this over alternatives such as polymarket_price or the Kalshi candlestick tools. The closing line 'Also answers this: kalshi_candlesticks, kalshi_candlesticks_batch' is ambiguous and could be interpreted as a compatibility note rather than a clear usage directive.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• racingandsports_match_listA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and open-world behavior, and the description adds valuable context: the return shape is the site's XHR feed and it may be Cloudflare-challenged from datacenter IPs. This goes beyond the annotations without contradicting them, providing deployment-relevant behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, using three short lines to convey purpose, return shape, auth, and a network caveat. Every sentence earns its place, with the main purpose front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no params, no output schema) and strong annotations, the description covers the essentials: what it returns, that no auth is needed, and a potential environmental issue. It doesn't detail the exact feed structure, but that is acceptable for a straightforward list endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description doesn't need to explain any. Baseline for no parameters is 4, and the empty schema is fully covered by the context signal of 100% schema_description_coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a sports match list for non-racing fixtures, distinguishing it from racing-focused siblings like racingandsports_todays_racing. The phrase 'the site's non-racing fixtures feed' provides specific scope, though the site itself is unnamed, leaving slight ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a practical usage caveat about Cloudflare challenges from datacenter IPs and notes that no auth is needed. However, it doesn't explicitly state when to use this tool versus other match-list tools or exclude any alternatives, leaving the usage context implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• racingandsports_todays_racingA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only and idempotent behavior, so the bar for additional transparency is lower. The description adds 'Auth: none needed' and describes the return structure, which is useful. However, it does not disclose potential rate limits, data freshness/timezone semantics, or any other behavioral nuances that might affect invocation expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-sentence purpose statement followed by a compact, precise type definition for the return value. It includes only necessary information (auth note, grouping logic, URL fields) without any filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no parameters and no output schema, the description is remarkably complete. It states what data is returned, how it is organized, the meaning of each field, and authentication requirements. The only minor omission is the timezone for 'today', but that does not undermine the overall completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the input schema fully covers parameter semantics. The description adds value by detailing the return structure, which helps the agent understand what to expect, but this is not strictly about parameter meaning. Baseline for zero-parameter tools is 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: returns today's race meetings across all codes (thoroughbred, harness, greyhound), grouped by country, with form-guide/results URLs. It specifies the resource ('today's race meetings'), the scope (all codes, grouped by country), and the output structure, making it distinct from many sibling racing tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternative racing tools such as betr_todays_races or tab_racing_meetings. It does not mention any trade-offs, exclusions, or preferred use cases beyond its inherent purpose of retrieving today's meetings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sleeper_trending_playersA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint and idempotentHint, so the bar is lower. The description adds useful behavioral context: return format (top-level array), semantics of 'count' (how many leagues made the move), need to resolve player_id via a roster or player file, and that no auth is required. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is reasonably concise and well-structured with clear sections: purpose, return format, example, auth. However, the final line 'Also answers this: espnfantasy_player_info.' is confusing and seems out of place, slightly detracting from clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with no output schema, the description covers the essential context: return format, count semantics, player_id resolution, authentication, and an example. It does not mention pagination or limit behavior, but the schema covers parameters. The odd cross-reference line slightly reduces completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear descriptions for all four parameters (limit, sport, add_or_drop, lookback_hours). The description's example shows a typical call but adds no additional meaning beyond 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Players being added or dropped most across all of Sleeper'—a specific verb+resource with scope ('across all of Sleeper'). It distinguishes itself from the player file download and sibling Sleeper tools by focusing on trending/waiver-wire signals.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an example and implies usage as a waiver-wire signal ('without downloading the 15 MB player file'), but it does not explicitly state when to use this tool over other Sleeper tools or when not to use it. The reference to 'esPNfantasy_player_info' is ambiguous and does not serve as a clear alternative comparison.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportmonks_standingsA
  3.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses several important behavioral traits beyond the readOnlyHint/idempotentHint annotations: the response shape is unverified and approximate, team names require the include=participant parameter, and authentication needs a user-provided SPORTMONKS_TOKEN. This is valuable context that helps the agent set expectations and avoid relying on unverified fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a one-line summary, return shape, caveat, example, and auth note. It is somewhat long but each part serves a purpose; the unverified-shape warning is particularly important. Slightly verbose but not wasteful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that there is no output schema, the description provides a detailed return shape, flags its unverified nature, includes a practical example, and states auth requirements. This covers all essential aspects for an agent to invoke the tool and interpret results, making it comprehensively complete for a read-only standings endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the schema already describes both parameters (100% coverage), the description adds meaningful usage context: a concrete example showing seasonId and include values, and a warning about the consequence of omitting include=participant. This goes beyond the schema's simple field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning a league table for a season, including a detailed return shape and an example. However, it does not differentiate this tool from sibling standings tools (e.g., pl_standings, apisports_football_standings), so it lacks the sibling distinction needed for a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternative standings tools. It does give parameter-level advice (e.g., without include=participant you only get team IDs), but that does not address tool selection. There is no mention of exclusions or when-not-to-use scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_cms_messagesA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, which cover safety. The description adds value beyond annotations by specifying the exact return shape ({messages:[{id, type, text}]}) and stating that no authentication is needed. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise—three short sentences, each carrying distinct value: resource scope, return format, and auth requirement. No fluff, well front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with no parameters, the description provides enough context: what it returns, the data structure, and auth. It could mention error cases or pagination, but these are not critical given the tool's simplicity and the annotation coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters, the schema already fully covers parameter semantics (100% coverage). The description is not required to add parameter details, and it adds no unnecessary information. Baseline of 4 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies the resource (sitewide CMS messages) and specifies it includes banners and notices, but lacks an explicit verb like 'get' or 'list'. The return format implies a list retrieval, making the purpose clear enough while not being fully explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the resource description—if you need sitewide CMS messages, this is the tool. However, no explicit alternatives, exclusions, or when-not-to-use guidance are provided, and the many sibling tools make some differentiation helpful.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_racing_challengesA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context by specifying the exact return shape ({challenges:[{id,name,status}]}) and the auth requirement ('Auth: none needed'). This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: a one-line summary, a return format line, and an auth line. Every sentence adds essential information, with no filler. This is a model of efficient structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple no-parameter feed tool, the description covers the essential aspects: what it returns and auth requirements. It provides an inline output schema to compensate for the lack of a formal output schema. A small gap is that it doesn't clarify the distinction between 'challenges' and 'promotions,' but overall it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so the schema coverage is trivially 100%. The baseline for 0 params is 4, and the description correctly omits any parameter details since none exist. No improvement needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'racing challenges / promotions' and states it is an 'All' feed, which distinguishes it from sibling tools like sportsbet_racing_allracing or sportsbet_promotions. The Returns line further specifies the output structure. However, it lacks an explicit action verb like 'List' or 'Get', making the purpose clear but not as crisp as it could be.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The word 'All' implies this is the go-to feed for racing challenges, but there is no explicit guidance on when to use this versus similar sibling tools such as sportsbet_promotions or sportsbet_popular_promotions. No exclusions or alternatives are mentioned, so the usage context is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_racing_futuresA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish read-only, idempotent, and open-world behavior. The description adds concrete return structure ({futures:[{marketId, name, selections...}]}) and explicitly states no authentication is required. This context goes beyond what annotations provide and helps the agent understand the response shape without overstepping.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: a one-line purpose statement, followed by a return schema snippet, and an auth note. Every sentence adds value, and no space is wasted.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless read-only tool, the description covers the essential information: what it returns and that no auth is needed. The absence of an output schema is mitigated by the inline return shape. It doesn't mention pagination or limits, but for this simple tool, the provided detail is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema is empty, so parameter descriptions are not needed. The description compensates by documenting the output format in detail, which is the only meaningful semantic for this no-arg call.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource: racing futures markets, specifically Cup outrights and long-running racing markets. The return format further confirms it returns a list of futures markets. However, it lacks an explicit verb like 'get' or 'list', and doesn't distinguish itself from similarly named sibling tools like pointsbet_racing_futures or tab_racing_futures_race, though the Sportsbet prefix helps.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you need racing futures/outrights, and 'Auth: none needed' provides a precondition. But there is no explicit guidance on when to use this tool vs alternatives such as entain_racing_future_markets or tab_racing_futures_race, nor any mention of scenarios where this tool is preferred or not.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsdataio_nfl_injuriesA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the read-only behavior is established. The description adds important beyond-annotations context: authentication requires a user-supplied key (SPORTSDATAIO_NFL_KEY, etc.), and the return shape is from vendor docs and unverified, alerting the agent to potential inaccuracies.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized, starting with the purpose, then the return shape, a verification caveat, an example, authentication requirements, and alternative tools. Each section is short and relevant, though the 'Also answers this' line could be phrased more clearly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with only two parameters, the description covers the essential context: purpose, output shape, example, auth needs, and alternative tools. The caveat about unverified shape is a valuable addition. It does not include explicit usage exclusions, but for this low-complexity tool, the description is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for both required parameters (season and week), achieving 100% schema_description_coverage. The description offers only an example invocation using season '2023' and week 1, which illustrates usage but does not add semantic meaning beyond what the schema already documents.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'NFL injury report for a week,' identifying the specific verb (report), resource (injuries), and scope (NFL, week). It also lists the expected return fields, reinforcing the purpose. However, it does not explicitly distinguish itself from sibling tools like mysportsfeeds_injuries, though it mentions alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: this tool should be used for NFL injury reports by week. It also notes that 'Also answers this: espn_site_call, espnfantasy_player_info, mysportsfeeds_injuries,' indicating alternative tools that can answer the same query. However, it lacks explicit exclusions or guidance on when to prefer this tool over those alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsgameodds_bookmakersA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context: the return shape (with field names), a clear caveat that the shape is from vendor docs and may be unverified, and the authentication requirement (SPORTSGAMEODDS_API_KEY). This goes beyond the annotations and helps the agent understand reliability and setup.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and every sentence serves a purpose: definition, return shape, reliability caveat, example, and auth. It is front-loaded with the core purpose, then adds essential caveats. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only listing tool, the description covers the essential aspects: what it returns, the shape, reliability uncertainty, and auth. The 'indexed' phrasing is slightly ambiguous but the example and shape clarify it. It is appropriately complete given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so the baseline is 4. The description references the output field 'byBookmaker' which gives useful context about how the returned IDs are used, but no parameter explanation is needed. The description does not detract from the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (bookmakers) and states that it returns the bookmakers indexed, along with the ids used in byBookmaker. The example 'Every bookmaker' reinforces that this is a list-all operation. However, it lacks an explicit action verb like 'List' or 'Retrieve', which slightly reduces clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The mention of 'ids used in byBookmaker' implies a use case: to obtain bookmaker IDs for use in other tools that require that parameter. This is useful but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusion or alternative guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsgameodds_leaguesA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare read-only/idempotent behavior, and the description adds critical context: the return shape is unverified vendor documentation, likely approximate, and requires inspecting the actual payload. It also discloses the need for a personal API key. This goes beyond the annotations and does not contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with purpose, followed by return shape, a caveat, an example, and auth note. Each section earns its place, though it is somewhat long; the vendor-verification caveat is important and justified.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides an approximate return shape, an example, and auth details, which is sufficient for a simple read-only list tool. It lacks a full enumeration of sportID values or error conditions, but the unverified-shape warning makes the agent well-prepared.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for the only parameter, sportID, with 'Restrict to one sport.' The description adds a concrete example using 'FOOTBALL', which offers slight extra value but does not enumerate valid values or add meaningful semantic depth beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as leagues with league IDs used by other tools (e.g., NFL, NBA, MLB), and includes the return shape with leagueID/sportID/name/enabled. It distinguishes from sibling sportsgameodds tools by emphasizing that other tools filter on leagueID, but it lacks an explicit verb like 'list' or 'get', relying on the 'Returns:' line for action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating 'the leagueID other tools filter on' and provides an example with 'sportID': 'FOOTBALL', plus notes auth requirements. It does not explicitly name alternative tools or state when not to use this tool, but the context is clear enough for an agent to know this is the reference for league IDs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsgameodds_teamsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the readOnly/openWorld/idempotent annotations by disclosing that the return shape is from vendor docs and unverified, instructing users to inspect the actual payload. It also clearly states the auth key requirement. This adds valuable behavioral context not present in annotations, though it omits details like pagination 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear shape definition, a prominent caveat about unverified vendor documentation, a concrete example, and an auth note. Each section serves a purpose and the formatting improves readability. It is slightly longer than necessary, but the added detail about uncertainty and authentication is justified.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 providing a detailed return shape and a usage example. It also covers authentication and warns about data reliability. It does not address pagination or error scenarios, but for a simple two-parameter lookup tool with strong annotations, the level of detail is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents both parameters with basic descriptions ('One team.' and 'League id.'), giving 100% coverage. The description adds a practical example for leagueID and clarifies that teamIDs are those used in events, but it does not explain how the optional teamID parameter behaves (e.g., single vs. multiple teams) or the default when no filter is provided. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as teams in a league and notes that the returned teamIDs are the ones used inside event objects, distinguishing it from sibling tools like sportsgameodds_leagues or sportsgameodds_events. However, it lacks an explicit verb (e.g., 'Get' or 'List'), starting with a noun phrase instead, which prevents a perfect score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete usage example with leagueID: 'NFL', and explains that teamIDs from this tool are referenced in event objects, implying when this tool is useful. It also states the auth requirement. It does not explicitly mention when not to use it or name alternatives, but the context is clear enough for a basic lookup tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_racing_raceA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, open-world, and idempotent behavior. The description adds valuable context by noting that results appear only after the race is run and that authentication is optional, potentially unlocking more data with TAB_CLIENT_ID/SECRET. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the main purpose, followed by a compact but informative return structure and auth note. It is concise, with no unnecessary filler, though the return field list adds some length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only fetch tool, the description covers expected data (odds, form, pools, results), the return shape, and authentication requirements. With annotations providing safety information, this is complete for typical use, though it does not address error handling or rate limits.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for all five parameters. The tool description does not add extra parameter semantics beyond what the schema already states, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly defines the tool as a 'full racecard for one race' with a specific list of included content (runners, odds, form ratings, pools, bet types; results after race). This distinguishes it from meeting-level or form-only siblings like tab_racing_meeting_races and tab_racing_race_form.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for obtaining comprehensive pre-race and post-race data for a single race, but does not explicitly mention when to use this tool over alternatives or provide exclusions. No sibling tools are referenced for comparison.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_sportA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond annotations by specifying the return structure (id, name, competitions) and auth requirements (works without a key, unlocked with client credentials). It also notes the inclusion of pseudo-sports. Annotations already cover read-only, idempotent, and open-world hints, and the description complements them without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise: one sentence for purpose, one for return shape, one example, and one for auth. Every sentence provides essential information without waste, and the most important info is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple lookup tool, the description covers purpose, input example, return format, and auth, making it self-contained. With no output schema, including the return shape in the description is especially useful. The note about pseudo-sports adds completeness for edge cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so both parameters (sport, jurisdiction) are documented. The description adds an example of the sport parameter ('AFL Football') and reinforces that raw spaces are used, but this largely mirrors schema information. It does not add significant new semantic meaning, keeping the score at baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  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 sport by name along with its competitions, using a specific verb and resource. It also notes coverage of racing-adjacent pseudo-sports, adding specificity. However, it does not explicitly distinguish itself from sibling tools like tab_sports, 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The purpose implies when to use it (to get a sport's competitions), and the example provides a concrete use case. However, there is no explicit guidance on when not to use it or mention of alternatives such as tab_sports or tab_competition, leaving usage implied rather than clearly outlined.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• theoddsapi_sportsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable context beyond those: it states the call is FREE with no quota cost, warns that the returned shape is from vendor docs and unverified against a live response, mentions the top-level array structure, and requires the user's own API key. These are meaningful behavioral disclosures that are not present in 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with separate lines for purpose, return shape, caveat, example, and auth. It is front-loaded with the most important info. However, the 'Example: In-season competitions' line is ambiguous and adds little value, and the description could be tightened without losing content. Overall it is concise and every major clause earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that this is a simple, single-optional-parameter tool with no output schema, the description provides sufficient context: return shape, auth requirement, quota impact, and a data quality caveat. The lack of an output schema is compensated by the explicit return example. Minor gaps include not clarifying the default filter behavior (in-season only) and the vague example, but these are covered in the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% description coverage for the single parameter 'all' ('true also returns out-of-season competitions'). The description does not add additional parameter semantics beyond the schema; it only mentions 'Example: In-season competitions,' which is somewhat vague and does not clarify the default behavior or the 'all' flag beyond what the schema already states. Per the rubric, a baseline of 3 is appropriate when schema coverage is high.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that this tool returns every sport/competition with its key, and explicitly positions it as the starting point for getting the sport_key needed by other tools. It distinguishes itself from siblings like theoddsapi_odds and theoddsapi_events by emphasizing its role as the discovery entry point. However, it lacks a crisp verb like 'list' or 'get' in the opening statement, relying on 'Start here to get' to convey the action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance on when to use this tool: 'Start here to get the sport_key the other tools need.' It also mentions that the call costs no quota, which informs usage. It does not explicitly name alternatives or when-not-to-use scenarios, but the 'start here' directive makes the usage context clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ufc_eventsA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: 'Auth: none needed', the full response structure, and that the three card times each include a timezone offset. This goes beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average but front-loads the core purpose in the first sentence. The return example and example call are both useful and earn their place. The structure is logical: summary, return shape, usage example, auth note.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 providing a detailed return structure example. It explains the meaning of the three card times and timezone offsets. It does not mention pagination behavior beyond the links.next/self in the example, but the schema covers param details and annotations cover the read-only safety profile.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so all 5 parameters are already described in the schema. The description's example call illustrates sort and limit usage but does not add meaning beyond the schema. It does clarify response fields like fight_card_time_early/prelims/main, but that is response semantics, not parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns 'UFC events — past and upcoming — with per-segment card times, venue and location.' This is a specific verb+resource with clear scope, and the plural 'events' distinguishes it from the singular 'ufc_event_card' sibling tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an example usage ('The most recent events' with sort and limit) which implies when to use it, but it does not explicitly state when not to use it or mention alternatives. No exclusionary guidance or sibling tool comparisons are given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wta_playersA
  3.9/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safe-read nature is established. The description adds meaningful behavioral context: the exact return structure, the ability to search by name with an example, the pagination parameters implicitly covered, and the note that no authentication is required. This goes beyond what annotations alone provide, making the tool's runtime behavior more transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with a clear intro, return structure, example, and auth note. It front-loads the main purpose and avoids fluff. There is minor redundancy in showing the return structure twice (once inside the intro and once in the dedicated 'Returns' line), but this repetition serves both an illustrative and a formal purpose, so it is acceptable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 specifies the return shape including pageInfo and content fields. It covers the search-by-name behavior, an example invocation, and how the result connects to downstream tools. The tool is relatively simple (3 optional parameters, no nested objects), and the description provides enough detail for an agent to invoke it correctly. External factors like error handling are not mentioned but are not essential for this catalogue tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for all three parameters (name, page, pageSize), so the baseline is 3. The description adds a concrete example for the name parameter ('Swiatek' → Iga Swiatek) and mentions paging through all, but does not add significant detail about page or pageSize beyond what the schema already states. Thus it offers marginal added value over the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies this as the WTA player catalogue and explains its two main operations: searching by name and paging through all players. It distinguishes itself from sibling tools like wta_player and wta_player_matches by noting that the player id feeds those tools. While the primary action verb ('list' or 'search') is implicit, the description's scope and resource are unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides concrete usage context: use this tool to search for a player by name or to page through the full catalogue, and the resulting player id can be passed to wta_player or wta_player_matches. It includes an example request and explicitly states no auth is needed. It does not explicitly mention when not to use it or compare with other listing tools, but the id-feeding guidance is a strong usage pointer.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_broadcast_channelsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool as read-only, idempotent, and open-world. The description adds valuable context by stating 'Auth: none needed' and specifying the exact return structure, which goes beyond the provided annotations. It does not mention pagination behavior or rate limits, but the added context is substantial.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: one sentence for purpose, one for return format, and one for auth. It is front-loaded with the core action and includes only essential information, with clear line breaks separating sections for readability.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with two pagination parameters and no output schema, the description covers the essential elements: purpose, return structure, and authentication. The schema and annotations fill in most remaining gaps, making the description sufficiently complete for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters (page and pageSize) having descriptive details. The tool description does not add any additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action 'List' and the resource 'broadcast channels', with additional details about media types (VIDEO/AUDIO/TEXT) and the count of 272. This unambiguously identifies the tool's purpose and distinguishes it from related broadcast tools such as regions or events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The purpose is stated clearly enough that usage is implied (to list broadcast channels). However, there is no explicit guidance on when to prefer this over sibling tools or any exclusions, leaving room for ambiguity in edge cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_broadcast_regionsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful behavioral details by specifying the return structure and that authentication is not required, which goes beyond the annotation fields and helps the agent understand side effects (none) and access requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very concise: one line for the main action, one for the return shape, and one for auth. Every sentence adds value and the structure is front-loaded with the primary purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with optional pagination, the description covers the core functionality, return format, auth requirement, and the fact that there are exactly 26 regions. The absence of an output schema is compensated by the explicit return shape. Only minor gaps exist, such as whether pageSize has a maximum or how pagination works, but the schema and pageInfo hint are sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema documents both 'page' and 'pageSize' with descriptions, achieving 100% coverage. The description does not add additional parameter semantics beyond what the schema already provides, so it matches the baseline of 3 for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it lists broadcast regions and includes the count (26) and that each region has a timezone. The verb 'list' plus resource 'broadcast regions' distinguishes it from sibling tools like afl_broadcast_region_get (single region) and afl_broadcasters_list (broadcasters, not regions).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or alternative exclusions are provided. However, as a list endpoint, it's implied that this is the right tool when you need all regions, while a specific region would use afl_broadcast_region_get. But this is not stated in the description, so guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_club_getA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as read-only and idempotent, so the description only needs to add extra context; it does so by specifying the return shape and that no auth is required. It does not contradict 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short, front-loaded sentences: purpose, return shape, and auth. No filler or repetition; every line earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-id tool with no output schema, the description covers the return fields and auth requirement, and the schema covers the id source. It is nearly complete, though it omits error/not-found behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter is fully documented in the schema (clubId, required, from afl_clubs_list, URL path), so the description need not repeat it. The description adds no parameter details beyond 'by id', so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get a single club by id', identifying the action, resource, and scope. It distinguishes itself from sibling tools like afl_clubs_list, which lists clubs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a club id is known, but does not explicitly contrast with list/idmap tools or mention when not to use it. The schema notes the id comes from afl_clubs_list, but the description itself offers no alternatives or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_competition_compseasonsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds value by specifying the return structure ({meta, compSeasons:[...]}) and clarifying that no authentication is needed. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the main purpose, followed by return format and auth requirement. Every sentence provides useful information with no redundancy. Three short lines cover what is needed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a simple list operation with two parameters, full schema coverage, and beneficial annotations. The description includes the return shape and auth requirement, making it largely complete. It does not explain pagination behavior, but pageSize parameter implies this and is documented in the schema. Overall, it is sufficiently complete for its complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: competitionId and pageSize both have descriptions. The tool description does not add meaningful extra context beyond the schema; it only restates the resource. With full schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' and resource 'comp seasons within one competition', clearly scoping the tool to a single competition. This inherently distinguishes it from sibling tools like afl_compseasons_list, which likely lists all comp seasons. The purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you need comp seasons for a specific competition and notes that competitionId comes from afl_competitions_list, providing a prerequisite. However, it does not explicitly state when to use this tool over alternatives like afl_compseasons_list, nor does it provide exclusion criteria. Usage is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_competition_getA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds valuable behavioral context: it specifies the return format ('{meta, competitions:[...]}') and explicitly states 'Auth: none needed', which is not covered by the annotations. This goes beyond the minimum and provides useful operational details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose in the first line. The return type and auth requirement are each given in a short, distinct line, making it highly scannable. Every sentence contributes meaningful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-ID lookup tool, the description is nearly complete: it covers the purpose, return structure, and authentication. The schema fully documents the parameter. Minor gaps include potential error behavior (e.g., when ID not found) and the contents of 'meta', but these are not critical given the simplicity and the presence of sibling tools for broader context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents the single parameter 'competitionId' with a description and example. The tool description only repeats that it uses an integer id, adding no new meaning beyond the schema. With 100% schema coverage, a baseline of 3 is appropriate, and the description does not compensate further.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Get a single competition by integer id' uses a specific verb (get) with a clear resource and scope (single by integer id), which clearly distinguishes it from the sibling 'afl_competitions_list'. It also provides the expected return shape, removing any ambiguity about what the tool retrieves.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: you need an integer competition ID, and it returns a single competition. However, it does not explicitly mention when to use this tool over alternatives like 'afl_competitions_list' or any exclusions. Guidance is only implicit through the word 'single', so it falls short of explicit 'when to use vs when not to use'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_content_photo_getA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds value beyond this by specifying the return shape '{id, type:'photo', title}' and stating 'Auth: none needed.' These details help the agent anticipate the response and confirm no authentication barriers, complementing the annotation-provided safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise—two short sentences plus a return line—with no wasted words. The key action is front-loaded, and every line adds relevant information: what it does, what it returns, and auth requirement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple getter with one parameter and no output schema, the description is sufficiently complete. It provides the return format and auth status, which partially compensates for lacking an output schema. It does not describe error behavior or edge cases, but these are less critical for a read-only fetch by id. Sibling tools exist, but the core purpose and call pattern are clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: the 'id' parameter is described as 'Content item id. Required — part of the URL path.' The description does not add further meaning beyond what the schema already states; it only repeats 'by id.' Since the schema fully documents the parameter, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description is specific: 'Get a single photo content item by id.' It clearly identifies the resource (photo content item) and the verb (get). It distinguishes from sibling tools like afl_content_photo_list (list vs single) and afl_content_video_get/text_get by the explicit 'photo' type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: call this when you have a content id and need a single photo item. However, it does not explicitly state when to use this versus alternatives, nor does it mention any exclusions or prerequisites beyond having an id. There is no direct guidance about selecting this over list or other content getter tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_content_photo_listA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds valuable context beyond that by specifying 'Auth: none needed' and outlining the response shape ({pageInfo, content:[{id, type:'photo', title, leadMedia}]}), which is especially useful since no output schema exists. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and front-loaded: a single action sentence plus a compact return structure and auth note. Every line provides useful information with zero waste, making it efficient for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list tool with 5 optional parameters, the schema fully documents the parameters and annotations cover safety, while the description fills gaps with auth requirements and return format since no output schema exists. The only missing element is explicit guidance on when to choose this over the photo 'get' sibling, but overall the description is sufficiently complete for a well-scoped list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with detailed descriptions (e.g., 'Rows to skip — this CMS surface pages with offset/limit, not page/pageSize'), so the baseline is 3. The description itself adds no parameter information, leaving semantics entirely to the schema, which is adequate but not enhanced.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and resource ('photo content'), making the tool's purpose unambiguous. It distinguishes from sibling tools like afl_content_text_list and afl_content_video_list by specifying the photo content type, and also provides the return structure.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives implied usage context by naming the operation ('List photo content') but does not explicitly state when to use this tool versus alternatives, such as afl_content_photo_get for fetching a single photo. It does not mention exclusions or prerequisites, relying on the tool name and sibling list for differentiation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_content_video_listA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, and the description does not contradict them. It adds beyond-annotation value by stating 'Auth: none needed' and disclosing the exact return shape ({pageInfo, content:[...]}), which helps the agent set expectations. Rate limits or result caps are not mentioned, but the added context is adequate for a simple list tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three terse, front-loaded segments: purpose, return shape, and auth. Every sentence earns its place with no filler, repetition of schema data, or redundant annotation restating.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description properly takes on return-value disclosure ('Returns: {pageInfo, content:[{id, type:'video', title, duration, onDemandUrl, additionalInfo}]}'). Combined with 100% schema coverage and strong annotations, the tool is mostly complete for a list operation; only usage guidance versus sibling content/live-video tools is left underspecified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline of 3 applies — the schema already documents all six optional parameters with clear descriptions and examples (e.g., 'Rows to skip — this CMS surface pages with offset/limit, not page/pageSize'). The tool description itself adds no parameter-level meaning, relying entirely on the rich schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'List video content (highlights, replays, press conferences).' It enumerates concrete content types and shows the return shape, clearly distinguishing it from sibling list tools like afl_content_text_list, afl_content_photo_list, and afl_content_promo_list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by enumerating the covered content types (highlights, replays, press conferences) but never explicitly states when to use this tool versus alternatives such as afl_content_video_get, afl_live_video, or entain_video_channels. No exclusions or preferred-alternative guidance is provided, which is a gap given the large sibling set.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_keyserver_url_signingA
  4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable context beyond that: it mentions the return value {signedUrl}, potential 401 error for anonymous tokens, and explicitly states 'Auth: none needed.' This clearly discloses behavioral traits and failure modes.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose and includes useful return/auth info, but the line 'Also answers this: ...' is cryptic and not immediately clear, reducing overall conciseness. It could be tightened by removing or explaining that note.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema, the description covers the main functionality, return value, auth requirements, and an error case. It is mostly complete, though it could benefit from explicit guidance on when to use it instead of sibling streaming tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes the single 'url' parameter as 'The unsigned HLS .m3u8 URL to sign.' The description adds minimal extra meaning (e.g., 'AFL HLS video URL'), so it does not significantly improve parameter semantics beyond the schema baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Sign an AFL HLS video URL for playback') and the resource (AFL HLS video URL), with a specific result (token-signed CDN URL). This distinguishes it from sibling streaming tools by focusing on the URL signing function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: use when an unsigned HLS URL needs signing for playback. However, there is no explicit when-to-use vs alternatives, and the line 'Also answers this: cricketaustralia_streams, entain_video_channels, pointsbet_inplay_streaming' is vague and does not clarify selection criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_players_listA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and open-world hints. The description adds useful context beyond annotations: 'Auth: none needed' and a concrete return structure. This gives agents confidence about access and expected response shape.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and well-structured: a one-line purpose statement, a return format block, and an auth note. Every sentence adds value with no waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, and the description covers purpose, return shape, and auth. The '17k+ all-time catalogue' note hints at the need for pagination, and the schema provides the necessary parameters. It lacks explicit mention of ordering or limits, but these are not critical for a basic list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear parameter descriptions for 'page' and 'pageSize'. The description adds no additional parameter guidance, but does not need to since the schema already documents them fully.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'List players', a specific verb with the resource, and adds '17k+ all-time catalogue' to specify scope. This distinguishes it from single-player tools like afl_player_get and mapping tools like afl_players_idmap.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage is implied by the name and description: use this to get a bulk list of players. However, it does not explicitly mention when to use this over alternatives like afl_player_get or how to navigate pagination beyond the schema.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_next5_racesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare this as read-only, idempotent, and open-world. The description adds the auth requirement ('Auth: none needed') and the return structure, providing useful context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded, with a one-sentence purpose, a concise return structure, and an auth note. No unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool, the description covers purpose, return format, and auth. However, the tool name suggests 'next5' but the description doesn't specify the number of races returned or ordering, leaving minor ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully described in the schema (100% coverage), so the baseline is 3. The description merely restates the filter role ('race-type + country filter') without adding new semantics or examples.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: it returns next races about to jump, with time-to-jump, filtered by race-type and country. This specific scope distinguishes it from siblings like betr_todays_races or betr_race.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving imminent upcoming races but does not explicitly mention when to use this tool over alternatives. There is no exclusion language or reference to sibling tools for other needs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_promotionsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the baseline transparency is high. The description adds valuable context by stating 'Auth: none needed' and explicitly showing the return structure, which goes beyond the structured annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded, with three terse components: purpose, return shape, and authentication requirement. Every sentence adds value, and there is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter, read-only tool without an output schema, the description is complete: it states what the tool returns (including a precise JSON structure), that no auth is needed, and the scope ('active'). Nothing essential is missing for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so per the rubric the baseline is 4. The description appropriately omits parameter explanations since there are none to define, and the return format is provided instead.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (active promotions) and its key metadata fields (title, end date, linked master events), effectively differentiating it from broader tools like betr_all_promotions. Although no explicit verb like 'list' or 'get' is used, the meaning is unambiguous from the context and the 'Returns' clause.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by specifying 'Active promotions' and notes 'Auth: none needed,' but it does not explicitly state when to use this tool over sibling alternatives (e.g., betr_all_promotions or pointsbet_promotions). The active vs. all distinction is present but not framed as a selection guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_race_formA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the tool as read-only and idempotent; the description adds 'Auth: none needed' and describes the return object, which is useful context. No contradictions with annotations. It doesn't disclose potential latency or failure modes, but the annotation coverage lowers the bar.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is compact and well-structured: a one-sentence summary, a return type block, and a short auth note. Every line adds value, with the main purpose front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a return shape summary and auth requirement, covering essential information. The simple two-parameter schema plus read-only annotations make this adequately complete, though a brief mention of alternatives would improve it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for both parameters (EventId and RequestingRace) with 100% coverage. The description adds no parameter-specific details, but the schema already handles it. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides a 'Detailed form guide for one race' and enumerates contents (runner history, comments, ratings). This distinguishes it from sibling racing tools like betr_race_flucs or betr_market_movers, and the return structure further confirms the single-race scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for obtaining a single race's form guide but does not explicitly state when to choose this over alternatives. 'Auth: none needed' clarifies prerequisites but there are no exclusions or comparisons to sibling form tools like pointsbet_racing_form or tab_racing_race_form. Score reflects missing explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketaustralia_contentA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: pagination behavior, the return object structure (pageInfo and content array), and that no authentication is needed. This goes beyond the annotations and helps set expectations for the agent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence purpose, followed by a return object example and an auth note. Every sentence earns its place, and the most critical information (what the tool does) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list tool with no output schema, the description provides a clear return shape, pagination details, auth requirements, and content type explanations. It does not cover every interaction (e.g., default pageSize limits or tagNames behavior), but the schema documents these parameters sufficiently. Overall, the description is complete enough for an agent to invoke and interpret results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all parameters with 100% coverage, including the contentType enum and defaults. The description provides minor additional context by clarifying what each content type contains (e.g., VIDEO highlights/replays), but it does not add significant parameter semantics beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('content list'), the resource ('Pulselive CMS'), and the scoping by type (VIDEO/TEXT/AUDIO/PLAYLIST) with specific examples (highlights/replays, articles). It is distinct from sibling tools, which focus on other Cricket Australia data like fixtures, teams, or standings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving paginated content lists by type, but it does not explicitly mention when to use this tool instead of alternatives (e.g., cricketaustralia_playlist for playlists specifically). It lacks explicit exclusions or alternative tool references, so the usage context is clear but not fully differentiated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketaustralia_playlistA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds the return shape and explicitly notes that no auth is needed, which is useful behavioral context beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences: purpose, return format, and auth. No redundant words; front-loaded with the main purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only get-by-id tool, the description covers purpose, return format, parameters (via schema), and auth. It doesn't need to explain more; the example return shape gives a clear idea of the response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with playlistId, pageSize, and detail already described. The description adds no further parameter semantics, which is acceptable given the schema is self-explanatory.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: a single Pulselive playlist by id, and clarifies it is a curated collection of videos like a match's highlights playlist. This clearly distinguishes it from the many other content and playlist-related siblings (e.g., pl_content, pl_video_latest).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It implies usage when you have a playlist id, but does not explicitly mention when to choose this over alternatives or provide exclusions. The context is clear but there is no comparative guidance, though no direct sibling does the same thing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketaustralia_runs_graphA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety. The description adds value by disclosing the exact return structure (innings array with fields like overs, overnightRuns, byesRuns) and stating 'Auth: none needed', which goes beyond what annotations provide. No contradictions found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise: two sentences plus a compact return example. It front-loads the core purpose, then provides the return shape and auth requirement. Every sentence contributes meaningful information with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with one required parameter and no output schema, the description is quite complete. It states what the tool does, the return structure, and auth requirements. It does not mention the optional format or jsconfig parameters, but the schema covers those, so this is not a significant gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameter meanings are fully documented in the schema. The description does not add extra parameter details beyond mentioning 'per fixture', which maps to the required fixtureId. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Run-progression (worm/manhattan) data per innings for a fixture' and identifies it as the data behind cricket.com.au's run graphs. This specific verb+resource+context distinguishes it from sibling cricket tools like scorecards, fixtures, and standings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when run-progression per innings is needed, but it gives no explicit guidance on when not to use it or which alternative tools to choose instead. Unlike the high-calibration example that names a sibling tool, this one lacks direct comparison, though the purpose is clear enough to infer typical use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketaustralia_scorecardA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds value by explicitly stating 'Auth: none needed' and providing the return structure, which is useful behavioral context beyond the annotations. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the purpose, followed by a structured return block. It includes only essential information: what the tool does, the return shape, and auth requirements. Every sentence earns its place, and the formatting makes it easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, but the description compensates by providing a detailed return structure. It also mentions auth requirements. While it does not describe limitations or error conditions, the simple read-only nature and the presence of responseError in the return make this sufficiently complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and each parameter already has a clear description in the schema (e.g., fixtureId from cricketaustralia_fixtures, optional competitionId). The description adds no additional parameter semantics beyond what is already in the schema, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Full match scorecard — per-innings batting, bowling and fall-of-wickets', which is a specific verb+resource pairing. It distinguishes this tool from siblings like cricketaustralia_fixtures (list of fixtures) or cricketaustralia_runs_graph (a graph of runs), by specifying the detailed per-innings statistics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating what data is returned (batting, bowling, fall-of-wickets), so an agent can infer it should be used when detailed scorecard data is needed. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites beyond the fixtureId parameter.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dabble_active_competitionsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, establishing the read-only nature. The description adds valuable context beyond annotations: the approximate count (~318), that no authentication is needed, and the exact return structure. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: it opens with the tool's purpose, then the usage flow, then field details, then return format and auth. Every sentence contributes. The only minor waste is the slight redundancy of the `sportId` filtering instruction already present in the schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only discovery tool with a single optional parameter, the description is fully complete. It provides scope (~318 competitions), the downstream recommendation, the response object shape, and authentication requirement, compensating for the lack of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully documents the single optional `sportId` parameter, including its source (dabble_sports) and the omit-for-all-sports behavior. The description repeats this filtering guidance but adds no new semantic detail beyond what the schema provides. Baseline of 3 is appropriate since schema coverage is 100%.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists every currently-bettable competition across all sports and serves as the discovery entry point. It also references the downstream tool dabble_competition_fixtures, which helps differentiate from that sibling. However, it does not explicitly contrast with the similarly named dabble_competitions sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: it is the discovery entry point, and users should pick an `id` and pass it to dabble_competition_fixtures. It also explains how to filter by `sportId`. It lacks explicit when-not-to-use guidance or direct comparison to alternatives like dabble_competitions, but the context is strong.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_fantasy_projectionsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as read-only, open-world, and idempotent. The description adds meaningful behavioral context by specifying the authentication requirement ('needs your own key in DATAGOLF_KEY') and the exact return shape, which is valuable since there is no output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, with a clear first sentence stating the function, a second listing the return structure, and a brief auth note. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of an output schema, the description compensates by showing the return object structure and the auth requirement. It covers the key context (site, slate) and all parameters are documented in the schema, though it would benefit from clarifying valid file_format values.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter (site, tour, slate, file_format) has a description in the schema. The tool description does not add extra parameter semantics beyond mentioning site and slate, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'DFS fantasy-points projections + salaries/ownership for a site + slate', clearly identifying the resource and parameterization. It also includes the return structure, distinguishing it from other datagolf tools like datagolf_hist_dfs_event_list. This is a specific, non-tautological statement of purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives context (for a site + slate) and mentions auth, but does not explicitly state when to use this tool over sibling tools such as datagolf_hist_dfs_event_list or datagolf_pre_tournament. There are no alternatives or exclusions, so usage guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_field_updatesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the description need not repeat those. It adds valuable context: the return object structure (event details and field array), inclusion of withdrawals and tee times, and an explicit authentication requirement (DATAGOLF_KEY). No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a clear purpose line, a return format line, and an auth line. Every sentence adds information and there is no waste. The front-loading of the purpose makes it immediately scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with 2 parameters and no output schema, the description is sufficiently complete: it describes what data is returned, gives an outline of the JSON structure, and mentions the required API key. Minor gap: 'current event' could be ambiguous if multiple events run concurrently, but overall it is adequate for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, covering both parameters (tour with enum, file_format). The description adds no extra parameter semantics beyond the schema, so the baseline of 3 is appropriate because the schema carries the heavylifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides the current event field with players entered, tee times, withdrawals, and current round. This distinguishes it from sibling datagolf tools (e.g., datagolf_pre_tournament, datagolf_in_play) by specifying a unique resource and content.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied via 'Current event field', signaling this is for live/current events rather than historical ones, but no explicit alternatives are named (e.g., 'for historical data use datagolf_hist_*'). There is no clear when-to-use or when-not-to-use guidance relative to the many datagolf siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_hist_outrightsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint annotations, the description discloses the exact return structure, clarifies that only one sportsbook is covered per call, and states the auth key requirement (DATAGOLF_KEY). This adds valuable behavioral context not available in annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences: purpose, return shape, and auth. Front-loaded with the primary function, no redundant or filler text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description includes a return structure, which is a good substitute. It also covers auth. It does not mention how to find event_id or any limitations beyond 'past event,' but the schema and return shape make it fairly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description adds a small nuance ('from one sportsbook' reinforces the 'book' parameter) but does not explain parameter syntax or values beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Historical opening/closing outright odds for a past event from one sportsbook,' which is a specific verb ('retrieve') and resource ('outright odds'), and the scope ('past event', 'one sportsbook') distinguishes it from current/live odds tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Historical... for a past event' implies usage for historical data, but no explicit alternatives are named (e.g., datagolf_outrights for current odds). The context is clear enough but lacks explicit when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_hist_resultsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe read-only nature is known. The description adds a required auth note (DATAGOLF_KEY) and provides the complete return structure with event_stats array, which is valuable behavioral context beyond the annotations. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: one purpose sentence, a return template, and an auth note. It is front-loaded with the tool's primary function and contains no fluff or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description provides the return shape and auth requirement, which are essential for a tool without an output schema. It omits details like pagination or rate limits, but for a historical data retrieval tool these are less critical. The PGA-only tour constraint is present in the schema, though not repeated in the description, so coverage is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all four parameters with descriptions, including event_id's source from datagolf_hist_results_event_list. The tool description does not add further parameter-level detail beyond what's already in the schema, so the baseline of 3 is appropriate given 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb+resource+scope: 'Historical event-level results for a past tournament', and enumerates the key data fields (finish position, earnings, FedExCup points, DG Points). This distinguishes it from sibling tools like datagolf_hist_rounds or datagolf_hist_odds, which serve different data needs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its usage context (past tournaments, event-level results) but does not explicitly contrast with alternative tools or state when to prefer this tool over others. The schema reference to datagolf_hist_results_event_list hints at a workflow, but exclusions or alternative recommendations are absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_hist_roundsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds the full return structure ('Returns: {event_id, event_name, event_completed, scores:[...]}') and an authentication requirement ('needs your own key in DATAGOLF_KEY'). It does not contradict the annotations. This adds meaningful behavioral context about output shape and auth without being redundant.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise, focused lines: the core purpose, the return structure, and the auth requirement. Each sentence adds necessary information with no filler or redundant content. It is front-loaded with the main functionality and well-structured for quick scanning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description compensates by providing a detailed return structure. It also covers authentication. It does not mention error conditions or how to find event_id, but the schema covers that. For a moderately complex historical data tool, the description is almost complete; a small example or note about the '...' fields would push it higher.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for all four parameters (100% coverage), so the baseline is 3. The description does not add any parameter-specific meaning beyond implying that the tool targets a specific past event (via 'event_id' and 'year' being required in the schema). No additional context is given for tour, file_format, or how to obtain event_id.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Historical round-by-round scoring + strokes-gained for every player in a past event.' This is specific, uses a clear resource (round-by-round player scores in a past event), and distinguishes it from sibling tools like datagolf_hist_results or datagolf_hist_event_list by emphasizing round-level detail and strokes-gained metrics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for past events ('Historical', 'past event') but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. The schema mentions event_id is from datagolf_hist_event_list, but that is not in the description. No clear guidance on when to choose this over datagolf_hist_results or other historical tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_live_tournament_statsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable context beyond annotations: it specifies the exact return structure (with example fields) and notes the auth requirement ('Auth: needs your own key in DATAGOLF_KEY'). This helps the agent understand data shape and setup needs.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: a one-line summary immediately explains what the tool does, followed by a compact Returns block and a necessary Auth note. Every section earns its place with no redundant or filler content, and the line breaks improve readability.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description adequately covers the return shape with a detailed Returns block, and it communicates the auth key requirement. It does not explain when an event must be live (e.g., tournament in progress) or discuss error cases, but the annotations and schema cover other aspects. This is reasonably complete for a live stats endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage with each parameter (round, stats, display, file_format) well-documented, so the description does not need to compensate. The description's Returns block provides example stat fields like sg_total and sg_ott, which hints at the stats parameter values, but this adds little beyond the schema's already clear explanations. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the function: 'Live per-player tournament stats (strokes-gained by category, accuracy, etc.) for the requested round.' This uses a specific verb and resource, and explicitly lists stat categories that differentiate it from sibling tools like datagolf_live_strokes_gained (which focuses only on strokes-gained) and datagolf_live_hole_stats. The Returns block further clarifies the output scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for live tournament stats by calling out 'Live' and 'tournament stats', but it does not explicitly state when to use this tool over alternative datagolf tools like datagolf_live_strokes_gained or datagolf_live_hole_stats. There is no mention of exclusions or alternative selection criteria, so guidance is only implied, not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_player_decompositionsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and open-world safety. The description adds valuable context: it requires a personal DATAGOLF_KEY, returns a specific object structure, and applies only to the current event. It does not mention data freshness or rate limits, but the existing annotations cover the safety profile, making this a solid addition.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the main purpose. The return shape and auth note are valuable and each sentence earns its place. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description provides the essential info for a read-only, open-world tool: what it does, the output structure, and the auth requirement. Some ambiguity remains around what constitutes the 'current event' (ongoing vs next scheduled), but the optional parameters and simple return format make this sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters (tour, file_format). The description adds no extra detail about parameter syntax or behavior, but the schema already fully describes the enum and defaults, so this is adequate per rubric baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Per-player skill decomposition for the current event' and enumerates the specific skills (driving, approach, putting, course-fit). It distinguishes this tool from sibling tools like datagolf_skill_ratings or pre_tournament projections by focusing on the current event and decomposition into skill contributions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for current event analysis and mentions the auth requirement, but it does not explicitly state when to use this tool vs alternatives (e.g., datagolf_skill_ratings, datagolf_pre_tournament) or provide exclusions. Usage context is clear but not contrasted with siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_player_listA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds valuable context beyond those: the exact return format (array of objects with five fields) and the auth requirement (DATAGOLF_KEY). This discloses practical behavioral details without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each earning its place: purpose, return format, and auth requirement. The description is front-loaded with the core purpose and contains no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one optional parameter, no output schema, and no nested objects, the description is nearly complete: it covers the purpose, the return structure (compensating for the missing output schema), and authentication. It could mention potential response size limits but does not need to for this level of complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the single optional parameter (file_format) is already fully documented in the schema. The description adds no parameter-level meaning, but per the baseline rule, a 3 is appropriate when schema already does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns a full player list with specific fields (dg_id, player_name, country, country_code, amateur), using 'Full player list' as a specific verb+resource. It distinguishes itself from sibling datagolf tools by focusing on the player list resource and enumerating the exact output fields.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the name and description: an agent needing player IDs or basic player info would select this tool. However, there is no explicit guidance on when to use it vs. alternatives (e.g., datagolf_player_decompositions or other datasource player lists), and no exclusions or alternative recommendations are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_rankingsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, open-world, and idempotent hints. The description adds valuable context: it explicitly states the auth requirement (DATAGOLF_KEY) and provides the complete return structure, including field names. This goes beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences: purpose, return format, and auth. It is front-loaded with the most important information and contains no redundant text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with no required parameters and no output schema, the description covers the essential aspects: the data returned (with structure) and the auth requirement. It is sufficiently complete for an agent to invoke successfully.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the only parameter (file_format) as 'Response format' with a default value. The description adds no additional information about this parameter, but since schema coverage is 100%, the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides 'Data Golf player rankings (top ~500) with skill estimate and OWGR rank.' This specifies the exact resource and output content, distinguishing it from sibling tools like datagolf_player_list or datagolf_schedule.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when rankings are needed, but it provides no explicit guidance on when to use this over alternatives or mentions any exclusions. Sibling tools are not referenced.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entain_featured_sliderA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds 'Auth: none needed' and a detailed return structure, which go beyond the annotations that only mark it read-only, idempotent, and open-world. This gives the agent practical information about invocation and response. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two lines: first line gives the purpose, second line details return and auth. It is front-loaded and every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with no parameters and no output schema, the description provides the complete return structure and auth requirement. It is sufficiently detailed for an agent to invoke and interpret the result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema provides no parameter meaning. The description appropriately omits parameter details and instead focuses on return structure. Baseline 4 for zero-parameter tools.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource ('featured slider events') and specifies it's the 'homepage hero carousel', which differentiates it from other entain tools. It lacks an explicit verb like 'list' or 'get', but the return structure implies retrieval. Among dozens of siblings, this is uniquely about the featured slider.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool versus alternatives, nor does it offer exclusions. However, the clear context ('homepage hero carousel') implies use for fetching the hero carousel events. There is no mention of alternative tools for this specific data.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entain_racing_meetingA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, signaling a safe read operation. The description adds valuable context by listing the return structure (compounds, domestic_countries, meetings, races, venues) and explicitly stating 'Auth: none needed', which goes beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded, with the core function stated in the first sentence. It then provides a return structure, an example, and an auth note—all relevant information with no redundant fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has only two parameters and no output schema, so the description's inclusion of the return structure and auth note compensates well for the missing schema. While it doesn't discuss alternatives, the overall description is sufficient for an agent to understand what the tool returns and how to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents both parameters with clear descriptions ('Race date, YYYY-MM-DD' and 'IANA timezone'), giving 100% coverage. The description's example repeats this information without adding new semantic constraints or format details, so it provides no significant additional parameter meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides 'All race meetings + races for one date', which is a specific resource (race meetings and races) with a clear scope (one date). It distinguishes itself from sibling tools like entain_racing_racecard or entain_racing_search by focusing on the full day's data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when needing a complete set of meetings and races for a single date, as shown in the Melbourne card example. However, it does not explicitly mention alternatives or state when not to use this tool, leaving the agent to infer the appropriate context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entain_racing_racecardA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description does not contradict any of these. It adds valuable behavioral context by enumerating the exact return structure, noting that the last element in price_fluctuations is the live fixed win price, and stating that no auth is needed. This goes beyond what annotations alone provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-line summary, a return-type breakdown, a concrete example, and an auth note. Every sentence is informative and the most critical information appears first, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the lack of an output schema, the description compensates by detailing the nested return keys (races, markets, prices, entrants, price_fluctuations, meetings) and providing an example. It also mentions the auth requirement and the origin of the id. It does not cover error conditions or edge cases, but it is sufficiently complete for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for the required 'id' (Race UUID from the meetings route) and the optional 'method' (with default 'racecard'). The description's example reinforces the id format but does not add semantics beyond the schema, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Full priced racecard for one race — entrants, fixed-odds fluctuations, form,' which clearly identifies the tool as providing a comprehensive racecard for a single race. This distinguishes it from meeting-level tools like entain_racing_meeting and search tools like entain_racing_search, and the specific content areas make its purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for a single race via the 'one race' phrasing and the example, and the schema hints that the ID comes from the meetings route. However, it does not explicitly state when to use this tool over sibling racecard tools (e.g., sportsbet_racecard, betr_race) or when not to use it. This is a clear gap compared to tools that name alternatives directly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entain_sport_event_cardA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by detailing the return structure (entrants, events, markets, prices, etc.), giving an example, and explicitly stating 'Auth: none needed' — information not covered by annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: a one-line purpose, a return structure line, an example, and an auth note. Every sentence earns its place, providing maximum information with minimal waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one parameter, no output schema), the description provides a solid return map, an example, and auth requirements. It could mention error behavior or the meaning of each return key, but for a read-only event card, this is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage with 'Sport event UUID (bare, no type prefix).' The description reinforces this with an example ID but adds no additional semantic meaning beyond what the schema conveys.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states exactly what the tool does: 'Complete event card — every market, selection and price for one sport event.' It lists the specific return keys and provides a concrete example, making it clear this returns full event detail for a single event, distinguishing it from generic event requests.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Complete event card' and the example imply it should be used when full event details are needed, but there are no explicit alternatives or exclusions. Sibling tools like entain_sport_event_request are not referenced, leaving the comparative usage implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_draftA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, and the description does not contradict them. It adds genuine behavioral context beyond the annotations: the auth requirement ('works without a key; ESPN_FANTASY_COOKIE unlocks more if set') and the precise return shape including status flags (drafted, inProgress, completeDate) and all pick-level fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tightly organized into four distinct sections: a one-line purpose, a compact return-structure spec, a minimal JSON example, and a one-line auth note. Each part earns its place, and there is no filler or repetition of the schema content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Because there is no output schema, the description compensates by inlining the full draftDetail/picks return structure, demonstrating a realistic call with an example, and disclosing auth behavior. Minor gaps remain — such as no explicit explanation of status-flag semantics or guidance for choosing among the game enum values beyond the schema — but overall the tool is well specified for a read-only data lookup.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: leagueId and seasonId are documented as required URL path parts, game has a full enum, and view is described as 'Leave as-is.' The description's example repeats these values (game=ffl, seasonId=2018, leagueId=1234), which reinforces usage but does not materially extend the schema's meaning, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening line 'Draft results — every pick in order with round, team, player, keeper flag and auction bid' names the resource (the fantasy draft) and enumerates the exact scope of what is returned, making the purpose unmistakable. It clearly distinguishes this from sibling espnfantasy tools like rosters, transactions, or standings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete example invocation ('Full draft board' with game, seasonId, leagueId) which implies when to use the tool, but it never explicitly states when to use it versus alternatives such as espnfantasy_teams or espnfantasy_transactions. Usage is implied through the example and content summary, not directly guided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_seasonA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint, idempotentHint) already convey safety profile. The description adds useful context: the exact return fields, an example usage, and authentication behavior ('works without a key; ESPN_FANTASY_COOKIE unlocks more if set'). This goes beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-line purpose, a return format block, an example call, and auth note. Every sentence earns its place with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read-only status tool, the description covers the return shape, an example, and auth requirements. It lacks edge-case behavior or error conditions, but these are less critical for a straightforward status endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and both parameters (game, seasonId) are well documented in the schema itself. The description adds an example that illustrates parameter values, but does not introduce new semantic information beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'One game-season's status' with a specific verb and resource, listing the key data points (current scoring period, start/end dates, active flag). This distinguishes it from sibling tools like espnfantasy_games or espnfantasy_league by focusing on a single season's status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an example call but does not explicitly state when to use this tool versus alternatives such as espnfantasy_status or espnfantasy_games. The intended use is implied by the title and content, but no direct 'use this when' or 'instead of' guidance is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_standingsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only and idempotent behavior, lowering the burden. The description adds useful context beyond annotations: auth behavior ('works without a key; ESPN_FANTASY_COOKIE unlocks more if set') and a detailed return shape. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and information-dense: a one-line summary, a clear return type, an example, and an auth note. Every sentence earns its place with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of an output schema, the description compensates by providing the return structure and an example. It doesn't elaborate on the view parameter's effect beyond the schema, but for a simple read-only standings tool, the description is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 four parameters. The description contributes an example invocation but no new parameter meanings beyond what the schema provides, justifying the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'League standings — records, points for/against, division and playoff seeding' and provides a detailed return object, making the tool's purpose unmistakable. It distinguishes itself from sibling tools like espnfantasy_teams or espnfantasy_rosters by focusing specifically on standings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when/when-not guidance or alternatives are given. The description implies use when league standings are needed, and the example shows a typical request, but it does not compare to other espnfantasy tools or explain when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_statusA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (read-only, open-world, idempotent), the description adds auth behavior (works without a key, cookie enables more) and the return object shape. This expands on the structured metadata, though it does not cover error conditions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: purpose, return shape, example, and auth note. Every sentence adds value and the format is scannable, with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Since there is no output schema, the description provides a useful return-shape outline and an auth note. It covers the core status fields, but the waiverProcessStatus sub-object is truncated and field meanings like previousSeasons are unexplained. For a simple status tool, this is mostly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema coverage, parameter descriptions already document game, view, leagueId, and seasonId. The description's example reinforces the combination but provides no new semantic details beyond the schema, earning the baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: retrieving league lifecycle status including current matchup period, latest scoring period, season activity, and waiver dates. This distinguishes it from sibling fantasy tools focused on rosters, scores, or transactions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by listing the status fields, but it does not explicitly state when to choose this over other espnfantasy_* tools or mention alternatives/exclusions. The example clarifies the input format but not the decision boundary.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• euroleague_roundsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds response structure and 'Auth: none needed', which is beyond annotations. No contradictory behavior disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is compact, front-loaded with purpose, and includes return shape, example, and auth – no waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-param read-only tool with no output schema, the description adequately explains the return shape and auth. It could mention ordering or phaseTypeCode meanings, but is otherwise complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers both parameters with descriptions (100% coverage). The example provides concrete values but does not add meaning beyond schema; baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states 'The rounds (matchdays) in a season, with their date windows' and 'Returns: {total, data:[...]}' – a specific resource with an explicit verb ('returns'). It distinguishes from sibling tools like euroleague_game, euroleague_seasons, and laliga_rounds by focusing on EuroLeague rounds.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides an example call but no explicit guidance on when to use this vs alternatives. No exclusions or mentioned alternatives. The use case is implied by the resource type.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fanduel_racing_messagesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds the exact response envelope and confirms no authentication is needed, providing useful behavioral context beyond the annotations. No contradictions exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise: three short sentences covering the resource, return format, and auth. Information is front-loaded, and every sentence earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only message lookup, the description adequately covers the response shape and auth. Since there is no output schema, providing the return format is helpful. It omits edge-case behavior like error handling, but that is not necessary given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All four parameters are fully described in the input schema with defaults and examples, providing 100% schema coverage. The description itself adds no additional parameter semantics, so the baseline for high schema coverage applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as site message strings (disclaimers, informational copy) for a namespace and provides the response structure. This distinguishes it from sibling tools like fanduel_racing_promotions and fanduel_racing_quicklinks, making its purpose unambiguous even without an explicit verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating what it returns, but it does not explicitly say when to use this tool versus alternatives. No exclusions or comparison with other FanDuel racing tools are provided, so guidance is only implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_event_statusA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable context beyond annotations by explaining the return structure and the critical meaning of 'bonus_added: false' (scores are provisional and may change). This is genuinely useful behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is reasonably compact and well-structured: purpose, return format, key semantic flag, example, and auth. Each sentence contributes value, though the example 'Is this gameweek settled?' is slightly redundant with the opening sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool without an output schema, the description covers the return shape and the meaning of the key field (bonus_added). However, the possible values for 'points' ('r'|'p'|'l') are not explained, leaving a minor gap in interpretation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline per rubric is 4. The description adds no parameter semantics because none exist, but it does mention auth (works without key), which is relevant context for invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: to check whether bonus points and league tables have been finalised for the current gameweek. It distinguishes from FPL sibling tools by focusing on finalisation status, though it uses a noun phrase rather than an explicit 'get' or 'check' verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: when you need to know if scores are FINAL, illustrated by the example 'Is this gameweek settled?'. It also implies when scores might change (bonus_added: false) but does not explicitly exclude alternatives or list when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_manager_picksA
  4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description thoroughly explains behavior beyond the annotations: it documents the return structure, interprets position and multiplier values, notes bench order, and discloses auth requirements. It does not contradict the read-only, idempotent, or open-world hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a clear purpose and uses a structured return-shape block that earns its place given there is no output schema. It loses a point because the 'Also answers this' line is confusing and adds noise rather than useful context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a complete return contract, field-level explanations, an example, and auth behavior. It also leverages the input schema for path and deadline details, so the overall definition is comprehensive for a relatively complex tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for both parameters, so the schema already carries the semantic weight. The description's example adds a concrete invocation but does not materially expand on what managerId or gameweek mean beyond what the input schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description specifies exactly what the tool returns: 'The exact XI, bench order, captain and chip a manager used in a gameweek.' This is precise and distinguishes it from sibling tools like fpl_squad or fpl_manager_history, which cover different FPL data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no explicit guidance on when to use this tool versus alternatives. The cryptic closing line 'Also answers this: espnfantasy_rosters, sleeper_league_rosters, yahoo_team_roster' is unclear and does not provide actionable when-to-use or when-not-to-use instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• jolpicaf1_constructor_standingsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds value by disclosing the return JSON structure and explicitly stating 'Auth: none needed.' This is more than sufficient for a read-only tool with no destructive behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the core purpose. It includes a useful example and an auth note, with no wasted words. Every sentence serves a purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description compensates for the lack of an output schema by providing a detailed return structure. It also includes an example and auth clarification. It does not mention pagination or limit behavior, but these are covered in the schema and are not critical for a simple read-only standings tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear descriptions for all parameters (season, limit, format). The description's example shows season and format in action, which is helpful but adds little beyond the schema. The limit parameter is not mentioned in the description, leaving the schema to carry that burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the resource: 'Constructors' championship standings.' It is unambiguous and distinguishes from siblings like jolpicaf1_driver_standings by explicitly specifying 'Constructors'. The example further clarifies the scope (2024 season). The verb is implicit but the intent is unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not explicitly state when to use this tool versus alternatives such as jolpicaf1_driver_standings. The example provides a concrete use case, but there are no exclusions or alternative recommendations. Usage is implied by the tool name and description rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• jolpicaf1_seasonsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable context by specifying the exact return structure (MRData with SeasonTable) and 'Auth: none needed', which are not present in annotations. It does not describe rate limits or pagination behavior, but for a simple list operation that is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: a one-line purpose, return format, example, and auth note. Every line adds value, with no filler or redundant repetition of schema annotations. This is appropriately sized for a simple paginated list tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity, rich schema coverage, and annotations, the description is sufficient. It provides the return shape (compensating for the absent output schema), an example, and authentication note, while the schema covers parameter details. No critical gaps remain for an agent to select and invoke this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with parameter descriptions for limit, format, and offset. The description contributes an explicit usage example ({"format": "json", "limit": 30}) that demonstrates how to request the first page, reinforcing the schema's guidance. It does not introduce new parameter semantics but adds a practical illustration.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool returns every F1 season from 1950 onward and provides a return example showing 'Seasons:[{season, url}]'. This clearly indicates a list/retrieve operation over a distinct resource (seasons) and implicitly distinguishes it from sibling tools like jolpicaf1_drivers and jolpicaf1_races. The lack of an explicit verb like 'list' is minor, but the example and return structure make the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description does not provide explicit when-to-use vs alternatives or exclusions. The example and read-only annotations imply it should be used when a user needs the catalog of F1 seasons, but no rival tool or alternative is referenced. This is an implied usage pattern rather than explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_marketA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, reducing the burden on the description. The description adds that no authentication is needed and shows the complete return object structure. These details provide useful behavioral context beyond the annotations, though they don't cover potential rate limits or edge cases.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and places the core purpose in the first sentence. The return structure is listed concisely and the auth note is clear. However, the final line 'Also answers this: polymarket_market' is terse and ambiguous, slightly harming clarity and structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only tool, the description is quite complete: it covers purpose, input source (via schema), exact return fields, and authentication. Since there is no output schema, the explicit listing of returned fields is especially valuable. The annotations cover safety and idempotency, making this a well-rounded description for the tool's scope.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, ticker, has 100% schema coverage, including that it comes from kalshi_markets and is part of the URL path. The description merely says 'by ticker,' which does not add additional semantic meaning beyond what the schema already provides. Therefore, the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'One market's full detail by ticker,' which clearly states the action (getting full detail) and the resource (a specific market) along with the required input (ticker). This distinguishes it from sibling tools like kalshi_markets (likely listing many markets) and other kalshi tools. The added note about polymarket_market does not obscure the primary purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the schema description indicating the ticker comes from kalshi_markets and that this tool provides full details for that ticker. However, the description does not explicitly state when to use this over alternatives like kalshi_orderbook or kalshi_trades, nor does it provide exclusion criteria. The phrase 'Also answers this: polymarket_market' hints at an alternative but lacks specificity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_orderbookA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds useful behavioral details: the exact return shape (orderbook_fp with yes_dollars and no_dollars arrays), empty arrays when nothing is resting, and no authentication requirement. This goes beyond annotations, though it does not discuss ordering, pagination, or failure scenarios.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: purpose in the first sentence, return format in the second, and an auth note in the third. Every sentence adds value without redundancy. It is front-loaded and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity, the description is nearly complete. It covers the core purpose, return structure, empty-order behavior, and authentication. Since there is no output schema, including the return shape is valuable. The only missing piece is explicit usage guidance relative to sibling tools, but that is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides full descriptions for both parameters (`ticker` required and `depth` with a description), so schema description coverage is 100%. The description does not add additional parameter semantics beyond what the schema already states, resulting in a baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Order book for one market — resting yes/no bids by price level (dollar-denominated).' This specifies the action (retrieve order book), the resource (one market), and the data type (resting bids). It distinguishes from sibling tools like kalshi_candlesticks or kalshi_market by focusing on order book depth and the 'one market' scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving order book data for a specific market, but it does not explicitly state when to use this tool versus alternatives such as kalshi_trades or kalshi_market. No comparative or exclusionary guidance is provided, so the usage context is only implied by the tool's purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_seriesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable context by specifying 'Auth: none needed' and providing the exact return shape, which goes beyond what annotations offer. It does not contradict any annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences plus a return-type block. Every sentence carries useful information: the first defines the action and scope, the second provides the return structure and authentication requirement. There is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one well-documented parameter) and the presence of strong annotations, the description is largely complete. It fully specifies the return value, which is essential since no output schema is provided. It could mention error behavior for unknown tickers, but that is a minor omission for a simple read-only endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers the single parameter seriesTicker with a description and example ('KXNBA'), so schema_description_coverage is 100%. The description's 'by ticker' merely restates the parameter's purpose without adding new semantic detail, so it meets the baseline but does not exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'One series by ticker' which clearly indicates a single-series lookup by its unique identifier, and enumerates the returned fields (title, category, settlement sources, fee structure). This distinguishes it from sibling tools like kalshi_series_list, which presumably returns multiple series, by emphasizing the singular scope and the ticker-based access.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'by ticker' implies the tool should be used when a specific series ticker is known, but it does not explicitly mention alternatives, exclusions, or when not to use it (e.g., when listing all series would be more appropriate). There is no reference to sibling tools like kalshi_series_list, so guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• laliga_player_statsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish readOnly and idempotent behavior. The description adds valuable behavioral context beyond those: the exact return JSON structure and authentication behavior (works without a key; LALIGA_SUBSCRIPTION_KEY unlocks more). This enriches the agent's understanding without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded, leading with the core purpose, then the return format, then auth details. Each sentence serves a distinct purpose with no redundancy or filler, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool, the description covers the purpose, expected output structure, and authorization context. It does not explicitly differentiate from similarly named tools like laliga_players_stats, but the singular scope is clear. It could mention error behavior for invalid slugs, but this is not critical given the simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the single required 'slug' parameter with 100% coverage, including that it is part of the URL path. The description adds no additional meaning beyond the schema's own description, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'One player's Opta stats' identified by slug. It distinguishes from sibling tools like laliga_players_stats (plural) by emphasizing singular usage, and the inclusion of the return structure (player_stats with id, name, slug, opta_id, team, stats) reinforces the resource being retrieved.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this tool is for retrieving stats for a single player via slug, and notes the slug requirement. However, it does not explicitly mention when to use this tool instead of similar siblings like laliga_players_stats or laliga_player, nor does it provide alternative guidance or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• laliga_teamA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds meaningful context beyond these by disclosing the auth requirement ('works without a key; LALIGA_SUBSCRIPTION_KEY unlocks more if set') and the exact return shape. This supplements the annotations without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: a one-line purpose, a return structure, and an auth note. No filler or redundant wording; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter team lookup, the description covers the resource, return fields, and auth behavior. The only notable omission is not pointing users to a tool like laliga_teams for discovering slugs, but this is a minor gap given the schema's examples and the simple scope.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the single 'slug' parameter, including examples and a note that it is part of the URL path. The description's mention of 'by SLUG' and the returned slug field adds little semantic value beyond what the schema already conveys.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (one La Liga team) and the lookup method (by SLUG), enumerating the content delivered (club info, colours, foundation, socials, competitions, venue). It distinguishes this singular team endpoint from its plural sibling laliga_teams and other La Liga tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'One team by SLUG' implies the tool is for fetching a specific team, but it does not explicitly state when to prefer it over alternatives like laliga_teams or how to obtain a valid slug. There is no mention of exclusions or alternate tools, leaving some implicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_resourcesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds modest context about resource categories but does not disclose behavior beyond what the annotations and zero-parameter schema make obvious, such as return format 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that immediately conveys the action and scope. The parenthetical examples are brief and useful without adding unnecessary noise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter listing tool with an output schema and safe-read annotations, the description is sufficient. It establishes the exhaustive scope ('all registered') and gives examples of what counts as a resource, though it does not mention output shape or caveats.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters and the schema is essentially empty, so the baseline of 4 applies. The description adds no parameter-level detail, but none is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'List all registered MCP resources.' It clearly distinguishes the tool from siblings like list_available_groups and list_tools_by_capability by focusing on 'resources' and illustrating with 'capability map, dispatcher catalogues, reference data.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage ('list all registered resources') but does not explicitly state when to choose this tool over related meta-tools such as list_available_groups or list_tools_by_capability, nor does it provide any exclusions or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_attendanceA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, idempotent behavior; the description adds 'Auth: none needed' and a detailed return shape, providing useful context beyond the structured metadata. No contradiction with annotations was found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences cover purpose, return shape, and authentication, with no wasted words. The description is front-loaded and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides the return shape and auth requirement, covering essential details for a simple read-only tool. It doesn't explore parameter interaction edge cases, but those are documented in the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description echoes the team/league/season scope but adds no syntax or format details beyond what the schema already documents. It marginally reinforces the meaning of teamId and leagueId.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's purpose: retrieving attendance figures for a team or league/season, including per-game and aggregate home/away/total gate data. This specific verb+resource phrasing distinguishes it from sibling tools like mlb_schedule or mlb_teams, which serve different data needs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for attendance lookups but does not explicitly state when to use it over alternatives or provide exclusions. Since no sibling tool directly targets attendance, the context is somewhat implied rather than clearly differentiated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_boxscoreA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the behavioral safety profile is covered. The description adds meaningful context: a detailed return structure and an explicit 'Auth: none needed' note, which goes beyond what annotations alone provide. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose in the first sentence. The Returns block is structured and informative, and the Auth line is a single useful addition. Every sentence earns its place, with no fluff or repetition of the name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only, idempotent boxscore tool with only two parameters, the description is sufficiently complete. The absence of an output schema is compensated by the inline Returns structure, and the auth/parameter requirements are clearly stated. It doesn't cover edge cases like invalid gamePk, but that's not required at this level of detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents both gamePk and timecode. The description does not add new parameter semantics beyond the schema, though it references mlb_schedule for gamePk which is also in the schema. Baseline 3 is appropriate when the schema carries the parameter documentation burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns a 'Full game boxscore' with specific details (batting/pitching lines, team totals, officials, top performers). This makes it distinct from lighter-weight siblings like mlb_linescore and is a specific verb+resource construction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use (when a complete boxscore is needed), and references gamePk from mlb_schedule as a prerequisite, but it does not explicitly contrast with alternatives like mlb_linescore or mlb_live_feed. No exclusions or alternative tool names are provided, so the agent must infer usage from context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_leaguesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description only needs to add behavioral context. It adds the return format and explicitly states no auth is needed, which are useful details beyond the annotations. No contradictions found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, front-loaded with the core purpose, and every line provides necessary information: examples, parameter hint, return type, and auth status. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only catalogue tool, the description, combined with the annotations and schema, provides everything needed: what it does, key parameter examples, return structure, auth requirement, and safety profile. No gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already explains all parameters. The description adds value by providing concrete example values (103, 104) and clarifying that sportId=1 corresponds to MLB, which reinforces the schema semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a league catalogue and provides concrete examples (American League 103, National League 104). It is specific about the resource (leagues) and the verb (catalogue/list), but it does not explicitly distinguish itself from sibling tools like mlb_divisions or mlb_conferences.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a useful usage hint ('Pass sportId=1 for MLB') and notes that auth is not needed, which helps the agent know when to use it. However, it lacks explicit when-to-use or when-not-to-use guidance and does not mention any alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_playbyplayA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, reducing the need for safety disclosure. The description adds valuable context beyond annotations by specifying the return structure (allPlays, scoringPlays, currentPlay) and explicitly stating 'Auth: none needed.' This helps the agent understand what to expect from the tool without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded. The first sentence delivers the core purpose, followed by a concise return structure and an auth note. Every element earns its place without wasted words. It is well-structured for quick parsing by an AI agent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (two parameters, no output schema), the description provides a helpful return structure and auth information. It lacks some context such as how to obtain gamePk or potential size of the payload, but these are either in the schema or foreseeable. Overall, it is reasonably complete for an agent to use effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both gamePk and timecode described in the schema. The description does not add any extra meaning to the parameters—it only mentions the schema's own descriptions are sufficient. Since the description's role is to add value beyond schema, and it doesn't, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Pitch-by-pitch / play-by-play log — every plate appearance with result, pitches, counts, runners and scoring-play flags.' This is a specific verb-resource combination that distinguishes it from siblings like mlb_boxscore or mlb_linescore, which focus on different aspects of a game.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied by the description: if you need detailed play-by-play information, this is the tool. However, there is no explicit guidance on when to choose this over alternatives (e.g., mlb_live_feed, mlb_boxscore) or when not to use it. The description lacks exclusion criteria or direct comparisons, earning a mid-range score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_player_searchA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish read-only, idempotent, open-world behavior. The description adds value by specifying the return structure and stating no auth is needed, but omits details on ambiguity handling, pagination, or rate limits. This is a strong addition 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is two concise sentences plus a return format and auth note. It is front-loaded, direct, and every sentence serves a purpose without any fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description clearly provides the return structure and auth requirement, covering the core use case. It lacks edge-case behavior (e.g., multiple matches, no results) but remains fairly complete for a simple search tool with good annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover both parameters (names and limit) fully, so the description does not need to add much. It provides no extra semantic detail beyond the schema, but with 100% coverage, baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses a specific verb (find) and resource (players), and clarifies it resolves a name to personId(s) and basic bio. This distinguishes it from sibling tools that retrieve players by ID, like mlb_player.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies use for name-based search, but does not explicitly contrast with alternatives such as mlb_player or mlb_people, nor does it state when to avoid this tool. Usage context is implied rather than explicitly guided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_schedule_postseason_seriesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, open-world, and idempotent hints. The description adds useful behavioral context: it specifies the return shape ('Returns: {series:[{series:{id, gameType}, totalItems, games:[...]}]}') and clarifies that no authentication is required. This goes beyond the annotations and gives the agent a clear picture of the response structure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is succinct, with information front-loaded. The first sentence explains the core purpose, followed by return format and authentication. There is no redundant or verbose content; every line adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (two optional parameters, no output schema), the description is quite complete. It provides the return shape, authentication requirements, and the grouping behavior. Minor gaps remain, such as what happens when season is null (defaults to current season?) or how sportId affects results, but these are not critical for basic usage and the schema provides defaults.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (both 'season' and 'sportId' have descriptions). The tool description does not add extra parameter-level meaning beyond the schema, but it does mention the return structure which gives some indirect context about how the parameters might affect the response. Since the schema handles parameter documentation, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action and resource: 'Postseason series view — games grouped by series (e.g. ALDS, NLCS, World Series).' It distinguishes itself from sibling tools like mlb_schedule and mlb_schedule_postseason by emphasizing group-by-series semantics. The examples of series add concrete clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context (this is for postseason series grouping) but does not explicitly mention when to use this tool versus alternatives, or exclude other tools. While the name and description imply the use case, it lacks explicit guidance such as 'for regular season, use mlb_schedule' or similar.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_team_alumniA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds valuable behavioral context beyond annotations by specifying the return format ({people:[{id, fullName, primaryPosition, mlbDebutDate}]}) and stating that no authentication is needed. This enhances the agent's understanding of expected output and access requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise, using three short lines to convey purpose, return format, and auth requirement. It is front-loaded with the core function and every sentence contributes value. No redundant information is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool, the description is sufficiently complete. It provides the return structure, auth requirement, and parameter scope. While there is no output schema, the inline return type covers this gap. The annotations cover safety and idempotency, and the schema covers parameter semantics. The only minor omission is explicit mention of pagination or limits, which is not critical for this simple read operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 three parameters (teamId, season, group) with their meaning and constraints. The description does not add additional parameter-level detail beyond what the schema provides, but the mention of 'hitting/pitching/fielding' reinforces the group values already present in the schema. Baseline 3 is appropriate since the schema carries the burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: retrieving former players (alumni) for a team, filtered by season and group (hitting/pitching/fielding). This specific verb+resource+scope distinguishes it from sibling tools like mlb_team_roster, which would focus on current players.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by specifying the required dimensions (team, season, group) and identifies the group options. However, it does not explicitly state when to use this tool versus alternatives such as mlb_team_roster, nor does it mention any exclusions. The context is clear but the guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_teams_affiliatesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds value by specifying 'Auth: none needed' and explicitly showing the return structure, which helps set expectations about the output shape. It does not hide any surprising behavior, and it contradicts no annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence purpose, a return-type template, and an auth note. Every line serves a distinct purpose and no words are wasted. It is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity, the description covers the essential aspects: what it does, what it returns, and auth requirements. There is no output schema, so the inline return definition compensates well. It could have mentioned that teamIds is required or explained the season parameter's role, but the schema already documents those, so the description is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has 100% description coverage for its three parameters (season, hydrate, teamIds). The description does not add any parameter-level detail beyond what is already in the schema, so the baseline of 3 applies. The return-field names (e.g., parentOrgId) are self-explanatory but not elaborated further.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: it returns a club's affiliated teams across minor-league levels. The 'Returns:' clause with a concrete object structure reinforces that this is a retrieval operation. It distinguishes itself from sibling tools like mlb_teams (which presumably lists major league teams) by its explicit focus on affiliates.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (when you need a club's minor-league affiliates), but there is no explicit guidance on when to prefer this over alternatives like mlb_team_roster or mlb_teams_history. No exclusions or 'use instead' notes are provided. The 'Auth: none needed' note is a permission guideline, not a usage-vs-alternative guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_teams_historyA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, and the description adds 'Auth: none needed' plus a precise return shape. This goes beyond the annotations by telling the agent what response to expect, though it does not cover error cases or open-world behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: purpose, return shape, and auth are each conveyed in a single line. No filler or redundancy is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only historical lookup tool with no output schema, the description provides the key return fields and auth requirement, making it largely self-contained. Minor gaps such as acceptable season format or invalid-team behavior prevent a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for teamIds, startSeason, and endSeason, so the baseline is 3. The description adds little parameter meaning beyond 'one or more teams' and the return structure; it does not clarify season formatting or ID types.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific resource and data scope: 'Franchise history (name/league/division changes over time) for one or more teams.' The 'Returns' line confirms the tool's purpose. It is clearly differentiated from sibling tools like mlb_teams or mlb_team, which would present current team information.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Franchise history... changes over time' implies the intended use case, but there is no explicit statement of when to use this tool versus alternatives such as mlb_teams or mlb_team, nor any exclusions or prerequisites. Guidance is inferred rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• motogp_standingsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover readOnly, openWorld, and idempotent hints. The description adds meaningful context by specifying the return structure (classification list with rider, team, constructor fields) and explicitly stating no authentication is needed, which goes beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured, starting with the core purpose, then the return shape, a concrete example, and authentication requirement. Every section earns its place without unnecessary fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of an output schema, the description provides a sufficient return outline and a realistic example. It is complete enough for a two-parameter read-only lookup, though the meaning of the 'file' field in the response is not explained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers both parameters completely, and the description adds no new constraints or formats beyond what the schema provides. The example gives concrete UUIDs but does not enhance the semantics of the parameters themselves.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns championship standings for a specific class and season, which distinguishes it from other standings tools and MotoGP session-specific endpoints. The example clarifies the exact resource being accessed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied through the description and example, but there is no explicit guidance on when to use this tool vs. alternatives like motogp_session_classification or other standings endpoints. No exclusions or alternative recommendations are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nascar_weekend_feedA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds a valuable warning that results are unsorted, include non-starters with finishing_position 0, and that the winner must be found via finishing_position == 1, not results[0]. This goes beyond annotations to disclose a real data quirk.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy due to the explicit return structure and warning, but every part earns its place: there's no output schema, so the return structure is essential; the sorting warning is critical for correct data interpretation; the example and auth note are useful. It is front-loaded with a clear summary.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there's no output schema, the description fully compensates by specifying the entire return JSON structure, highlighting the non-sorted/non-starter quirk, providing a concrete example, and noting auth requirements. Combined with the well-covered schema and annotations, the tool is fully understandable for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are fully documented. The description adds a concrete example and notes that raceId comes from nascar_race_list, but this is marginal. It doesn't introduce new parameter semantics beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening line specifically states what the tool does: returns a complete race weekend including finishing order, laps led, points, status, plus practice and qualifying runs. This clearly distinguishes it from sibling tools like nascar_race_list, which provides a list of races, making the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through the example (using raceId from nascar_race_list) and the mention of race weekend vs race list, but it doesn't explicitly state when to use this tool instead of alternatives or list exclusions. The guidance is contextual rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhl_rosterA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds meaningful behavioral context beyond those hints by specifying the exact return structure (three arrays, NOT one players list), listing output fields, and stating 'Auth: none needed.' This enriches the agent's understanding of the tool's behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and concise: a one-sentence summary, a clear return format block, a concrete example, and an auth note. Every section adds value without redundancy, and the most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description provides a detailed return structure with fields and an example, making it complete for typical use. It does not cover edge cases (e.g., empty rosters, null headshots) but is sufficient for the tool's simple parameter set.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes both parameters (team abbreviation and season format) with 100% coverage. The description provides an example ('team': 'TOR', 'season': '20242025') that reinforces the schema but does not add new semantic meaning beyond what's already documented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: returns a club's full roster for a season, split by position, with specific fields. It distinguishes itself from sibling tools by focusing on roster composition and adding the explicit note about three parallel arrays rather than a flattened list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (for retrieving a roster) but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or mention sibling tools like nhl_player or nhl_schedule. The example and return format help, but explicit guidance is missing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_championship_teamsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, idempotent, and open-world behavior. The description adds useful context: the return array shape with specific fields, the before/after session semantics, and the absence of authentication requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise: two sentences plus a return format and an auth note. It is front-loaded with the main purpose and contains no wasted text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with comprehensive schema and annotations, the description covers the return format and the before/after context. The schema clarifies session_key as 'Race session key', and the return field list provides sufficient detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all three parameters (session_key, meeting_key, team_name) with 100% coverage. The description does not add parameter-level semantics beyond the schema, so the schema carries the burden and is adequate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as retrieving constructors' championship standings with positions and points before and after a session. This distinguishes it from driver championship standings (e.g., openf1_championship_drivers) and other race-specific tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for constructor/team championship standings based on the name and content, but it does not explicitly state when to use this tool over alternatives or provide exclusions. No alternative tools are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_lapsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds valuable context: the exact return shape (top-level array with field list), the 'Auth: none needed' note, and the pit-out flag. This goes beyond what annotations alone provide, without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: first sentence states the purpose, second provides return fields, third handles auth. No filler or redundant content; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only data retrieval tool with no output schema, the description provides a complete field list and auth requirement, which gives the agent a solid mental model. It could be more explicit about whether results include all drivers when driver_number is omitted, and the exact format of segment colours, but overall it is sufficiently complete for a simple read operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter (lap_number, meeting_key, session_key, driver_number) is already documented. The description's mention of 'for a driver' reinforces the driver_number parameter but does not add new parameter syntax or format details beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the exact resource ('Per-lap timing for a driver') and enumerates the specific data fields returned (lap/sector durations, speed-trap speeds, segment colours, pit-out flag). This clearly distinguishes it from sibling F1 tools like openf1_pit or jolpicaf1_laps.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the purpose ('per-lap timing for a driver'), and the schema notes driver_number is 'strongly recommended.' However, there is no explicit when-to-use guidance, alternatives named, or exclusion such as 'for pit stops use openf1_pit.' It relies on the agent inferring context from the name and description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_pitA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool as read-only and idempotent. The description adds useful information about the return format and that no authentication is needed, which goes beyond the annotations. It does not discuss potential pagination or data nuances, but given the annotations, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, starting with the tool's purpose, followed by the return structure and auth requirement. Every sentence adds value, and there is no redundancy or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description effectively documents the return fields and their meanings. It also covers authentication. It lacks some details like the use of 'latest' for session_key, but the schema handles that, and the tool is simple enough that the description is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for all four parameters. The tool description does not add any parameter-specific context beyond what the schema already provides, so it meets the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that this tool provides pit stop data, specifying the exact metrics (lap, total time in pit lane, stationary stop duration) and the return structure. This distinguishes it from other openf1_* tools like openf1_laps or openf1_stints.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving pit stop data but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The context is clear from the name and description, but no direct guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_race_controlA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, so the description adds value by disclosing the return format (top-level array with specific fields) and that no authentication is needed. This goes beyond the annotations and helps set expectations for the tool's output and access.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, providing a one-line summary, a return format specification, and an auth note. Every sentence adds useful information with no redundancy or fluff, making it easy to scan and understand quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity, the description covers the essential return structure and auth requirement, which is especially helpful since there is no output schema. It lacks explicit details on default behavior (e.g., whether all messages are returned when no filters are applied), but the parameter schema compensates, making it sufficiently complete for a read-only feed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with clear descriptions (e.g., flag, category, lap_number, meeting_key, session_key, driver_number). The description does not add any additional parameter semantics, so it relies on the schema—meeting the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: it retrieves race-control messages, listing specific message types (flags, safety cars, incidents, investigations, penalties) and identifies itself as 'the official message feed.' This distinguishes it from sibling OpenF1 tools like openf1_laps or openf1_car_data by specifying the resource and scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied through the description ('official message feed') and the listed message categories, making it clear this tool is for race-control data. However, there is no explicit guidance on when to use this versus other OpenF1 tools, nor any when-not-to-use or alternative recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openligadb_matchA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the description need not restate them. It adds useful context: 'Auth: none needed' and a full return structure with field names and types. This goes beyond the minimal annotation coverage and helps the agent anticipate the response, though it doesn't cover edge cases like missing IDs or errors.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded. The primary purpose is stated in the first sentence, followed by the return shape, a practical example, and the auth note. Each sentence earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only single-parameter tool, this description covers the key elements: purpose, return payload, example invocation, and auth. It doesn't explain how to obtain a matchId within the description, but the schema and sibling list tools fill that gap. The lack of an output schema is partly mitigated by the inline return field list.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes the only parameter (matchId) with type, required flag, and provenance ('from either match-list tool'). The description adds a concrete example value, but no additional semantic detail beyond the schema. This matches the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific, action-oriented statement: 'One match by id, with goals and scorers.' This clearly identifies the tool as a single-match lookup and highlights the key included data (goals, scorers), distinguishing it from sibling list-type tools like openligadb_season_matches and openligadb_matchday_matches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when a specific match ID is known (via the example and 'by id'), but it never explicitly states when to prefer this tool over alternatives. The input schema hints that the matchId comes from a match-list tool, but that guidance lives outside the description itself. This leaves usage context mostly implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pandascore_playersA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable context beyond that: the exact return shape (fields and nesting), a prominent caveat that the shape is unverified from vendor docs, and the authentication requirement via PANDASCORE_TOKEN.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-line summary, return shape, verification note, example, and auth requirement. Every sentence carries necessary information with no fluff, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With four documented parameters, read-only hints, and no output schema, the description provides a full picture: return shape, example, and auth. It does not explain pagination behavior in detail or how to discover videogame slugs, but given the moderate complexity and existing annotations, it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all four parameters with descriptions (100% coverage), so the baseline is 3. The description adds an example for filter_videogame and implies pagination through page/per_page, but it does not enrich parameter understanding significantly beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Esports players with role, nationality and current team,' which clearly identifies the resource (esports players) and the fields returned. It differentiates from sibling tools like pandascore_teams and pandascore_matches by focusing on players, though it lacks an explicit verb like 'list' or 'retrieve'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example 'Dota 2 players {"filter_videogame": "dota2"}' provides concrete context for when to use the tool and how to filter by videogame. However, it does not mention alternatives or when not to use this tool, stopping short of the explicit guidance that earns a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_league_matchupsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as read-only, idempotent, and open-world. The description adds the return payload structure with fields like hasMarkets and isLive, plus a note that authentication is not required, giving useful behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: one purpose sentence, a return format block, and an auth note. Every line adds value and the key info is front-loaded in the first sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter listing tool, the description covers the return structure, auth requirement, and league-based scoping. No output schema exists, so the inline return type is essential and provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter leagueId has 100% schema coverage, including its source (pinnacle_sport_leagues) and URL path status. The description doesn't add parameter-specific details but doesn't need to since the schema already defines it clearly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns all matchups for a single league, with the NBA example providing concrete scope. This distinguishes it from sibling tools like pinnacle_sport_matchups and pinnacle_league_matchups_live by its specific league-level granularity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context (all matchups for one league) but does not explicitly mention alternatives or exclusions. While the sibling names hint at related tools, the description itself doesn't say when to prefer this over pinnacle_league_matchups_live or pinnacle_sport_matchups.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_sport_leaguesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds value by specifying the exact return structure (top-level array of objects with id, name, group, isFeatured, matchupCount) and noting that no authentication is needed, which goes beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and efficiently structured: a one-line purpose, a return shape, an example, and an auth note. Every line contributes necessary information with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only one parameter and no output schema, the description covers the essential return structure and auth, making it sufficient for an agent to invoke correctly. It misses edge-case details like error behavior, but given the tool's simplicity, it is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for the single sportId parameter, including examples and its origin from pinnacle_sports. The description's example repeats this information without adding any new semantic detail beyond the schema, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool returns leagues (competitions) for one sport with feature/group info, and it lists the exact return fields. This distinguishes it from sibling tools like pinnacle_sport_matchups and pinnacle_league_matchups, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an example ('Baseball leagues {sportId: 3}') and notes it is for one sport, which implies when to use it, but it does not explicitly say when not to use it or mention alternative tools for similar data. The guidance is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_sportsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety. The description adds 'Auth: none needed' and the exact return shape with field names, which is valuable behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: one line for purpose, one for return shape, and one for auth. It front-loads the main purpose and every line provides necessary information with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter read-only tool, this description is largely complete: it states the output, field names, array type, and authentication. The only missing piece is guidance on when to use this specific tool among the many Pinnacle siblings, but the simplicity of the operation makes this a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so there is no parameter semantics to explain. Per the rubric, a 0-parameter tool starts at a baseline of 4, and the description does not need to add parameter details, though it does specify the return fields.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'All sports with their matchup counts and primary market type' and the subsequent 'Returns' line clarifies the action. It clearly identifies the resource (sports) and the scope (all), distinguishing it from sibling Pinnacle tools like pinnacle_sport_matchups or pinnacle_sports_live.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus related Pinnacle tools. It does not mention alternatives, exclusions, or specific use cases, leaving the agent without context for selection among many siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_contentA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral context: return shape (pageInfo + content array with fields), auth ('none needed'), and an example payload. It does not mention pagination details beyond pageInfo, but the provided info is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: one line of purpose, a return shape, a minimal example, and an auth note. Every sentence earns its place with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list/search tool with 8 params and no output schema, the description is complete enough: it covers purpose, filters, return shape, example, and auth. It does not detail pagination fields or error behavior, but that is acceptable for a read-only list tool with rich annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and each parameter already has a descriptive comment. The description names the conceptual filters (content types, entity references, tags) and provides a concrete example, but it does not add extra semantics beyond what the schema already documents. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb-resource pair ('Content list/search') and clearly states the scope: articles, video, photos, with filtering by content types, entity references, and tags. This distinguishes it from sibling tools like pl_content_item (single item) and news/video-specific tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied through the action 'list/search' and the example 'Latest articles + videos', but there is no explicit guidance on when to use this tool instead of alternatives like pl_content_item or pl_news_latest. No exclusions or prerequisites are stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_content_itemA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly and idempotent hints, so the safety profile is covered. The description adds valuable context beyond annotations: 'Auth: none needed' and the return shape ('Returns: {id, type, title, description, date, body, ...}'). This gives the agent expectations for the response without conflicting 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, containing only two sentences plus an auth note. It front-loads the core purpose, includes return format, and states authentication requirements. No filler or repetition—every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-item getter, the description provides sufficient context: type enumeration, id usage, return shape, and auth. It lacks details on the 'detail' parameter options and potential error cases, but the schema covers required fields. Overall, it is nearly complete for this complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter described (lang, type, detail, contentId). The description itself does not add additional parameter semantics beyond what schema already provides, though it does repeat the type enumeration. Baseline 3 is appropriate since the schema carries the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves a single content item by type and id, listing the exact allowed types (TEXT/VIDEO/PHOTO/PLAYLIST/PROMO/AUDIO). This distinguishes it from sibling tools like 'pl_content' (which likely lists items) and other content-specific getters. The verb is implicit but unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: use this when you need one specific content item by type and id. However, it does not explicitly contrast with alternatives like 'pl_content' for listing, nor does it state when not to use this tool. No explicit exclusions or alternative references are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_matchA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly/idempotent/openWorld, so the description doesn't need to repeat that. It adds value by stating 'Auth: none needed' and enumerating the return fields, which gives the agent clear expectations about the response. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: first states purpose and distinction, second lists return fields and auth requirement. Every sentence earns its place, and it is front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool, the description covers purpose, return fields, auth, and id provenance. It is sufficiently complete for an agent to invoke, though it omits potential error behavior, which is acceptable given the low complexity and strong annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides a rich description of the id parameter (format, example, source, URL path), so the description adds no additional parameter semantics. With 100% schema coverage, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves a single match's detailed information ('match centre') and distinguishes it from the list-level tool by noting it is 'richer than the list item; adds seasonInfo.' The return field list further reinforces the specific purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when richer match detail than the list item is needed, but it does not name alternatives like pl_match_events or pl_match_stats, nor does it provide explicit when-not-to-use guidance. The usage context is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_match_commentaryA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the operation as read-only and idempotent, so the safety profile is clear. The description adds useful context beyond annotations: it states that the result is paginated, provides the return shape ({pagination, data:[...]}), and explicitly notes 'Auth: none needed.' These details help the agent understand the response format and access requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise: a one-line purpose, a return shape, and an auth note. Every sentence adds value with no redundancies, and the key information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description provides the return structure and notes pagination, which is crucial since no output schema is present. It briefly mentions auth, but does not explain how to use next_cursor for pagination or the meaning of all data fields (e.g., type, team1, team2). Given the simplicity of the tool and the strong annotations, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of the parameters with descriptions, including defaults and types. The description adds no additional parameter-specific semantics beyond the schema, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool provides a 'live text commentary feed for a match (paginated)', which is a specific verb+resource combination. It clearly distinguishes itself from sibling tools like pl_match_events or pl_match_stats by focusing on commentary.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for retrieving live text commentary, but it does not explicitly state when to use it instead of alternatives such as pl_match_events or pl_match_stats. No exclusions or alternative tool references are given, so the guidance remains implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_match_lineupsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints, establishing a safe read-only profile. The description adds 'Auth: none needed' and a return structure, which are useful behavioral/contextual details beyond annotations, though it doesn't mention rate limits or error cases.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences cover purpose, return format, and auth. Information is front-loaded and every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool, the description is mostly complete. It provides the return structure, essential given no output schema. However, it lacks mention of data availability (e.g., lineups not published until a certain time) or field interpretation details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with the parameter 'id' described as 'Match id. Required — part of the URL path.' The description adds no further meaning to the parameter, so the schema carries the full burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves match lineups with home/away team players, formation, and subs. This specific resource and data fields distinguish it from sibling tools like pl_match or pl_match_stats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for lineups but provides no explicit guidance on when to use it vs alternatives, nor any exclusions. The agent must infer from the tool name and description alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_news_popularA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavioral context beyond the annotations by specifying the return format (top-level array with fields), confirming no auth is required, and introducing the 'smart-ranked' concept. Since readOnlyHint, openWorldHint, and idempotentHint are already provided, the additional return-structure and auth details are valuable. It does not go into depth about ranking logic or pagination, but it covers the essentials for a simple read-only tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, covering purpose, return format, and auth in three short segments. There is no redundancy or filler content. The most important information is front-loaded, and every sentence contributes useful details for the agent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with two optional parameters and no output schema, and the description provides the return structure and auth requirements, which is largely sufficient. However, it does not explicitly identify the domain (Premier League) or explain what 'smart-ranked' means, leaving minor gaps. The level of detail is adequate for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters, with clear descriptions for 'limit' and 'recency'. The tool description only repeats the recency concept without adding new parameter context. Since the schema already fully documents the parameters, the description provides minimal additional semantic value, making a baseline score of 3 appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Popular news over the last `recency` hours, smart-ranked,' which identifies both the action and the resource. It also distinguishes itself from sibling tools like pl_news_latest and pl_video_popular by specifying 'popular' and the recency window. The verb is implicit (retrieve), but the scope is concrete and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through the recency parameter and 'smart-ranked' but does not explicitly state when to use this tool versus alternatives. It lacks any mention of exclusions or alternative tools (e.g., pl_news_latest for latest news). The guidance is sufficient for a basic understanding but not for optimal tool selection in all cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_structureA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover read-only, open-world, and idempotent behavior, so the safety profile is already established. The description adds the return shape and an auth note, which is useful, but it does not disclose additional behavioral traits like pagination, error handling, or data freshness. Thus, the description provides some but not rich context beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short, front-loaded sentences: a clear purpose line, a return shape line, and an auth line. Every sentence contributes useful information without repetition or fluff, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two well-documented parameters and supporting annotations, the description covers the core aspects: what it returns, the expected structure, and auth requirements. It is complete enough for an agent to invoke it correctly, though a bit more context about the structure fields would elevate it further.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema documents both parameters fully, with descriptions for cid ('Competition id (8)') and sid ('Season id (the starting year; 2025 = 2025/26)'), achieving 100% coverage. The description adds no param-specific meaning, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (season structure) and its scope (current phase + phase/matchweek layout for one season). The 'Returns' line signals a retrieval operation, and the tool is distinguishable from siblings like pl_current_gameweek or pl_matches by focusing on the overall structure.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: this tool is for retrieving a season's structure. It specifies the return object and the absence of auth, but it does not explicitly mention alternatives or when not to use it. However, the use case is well implied, so it earns a 4 rather than 3.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_team_statsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety. The description adds valuable context: the all-time scope, the count of metrics (~130), the return structure with example keys, and the auth requirement. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: one line for the main purpose, one for return format, and one for auth. Every sentence earns its place without redundancy or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 providing a return structure example, the approximate number of metrics, and the all-time scope. It also covers authentication. The lack of a full metric list is acceptable for tool selection purposes, making the description sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and both cid and tid have descriptive entries. The description does not add any parameter-specific information beyond what is already in the schema, such as noting they are required and part of the URL path. Baseline 3 is appropriate given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns team aggregate stats with all-time competition scope and ~130 Opta metrics. It provides a concrete return example, making the purpose unambiguous. This distinguishes it from sibling tools like pl_team_form or pl_team_leaderboard by specifying 'aggregate stats' and 'all-time'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving historical team statistics but does not explicitly contrast with alternatives such as pl_team_form or pl_standings. It states that no authentication is needed and that both parameters are required, but lacks explicit when-to-use or when-not-to-use guidance relative to other tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_preprice_multisA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds context beyond annotations by specifying the return structure and explicitly stating that no authentication is needed. It also notes the constraint of one pre-built multi per event, which clarifies expected output size. The annotations already cover read-only, idempotent, and open-world hints, so the bar is lower; this description meets it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, with only three short segments: purpose, return format, and auth. Every line adds value, and the most critical information (what it does) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter read-only tool with good annotations, the description is largely complete. It covers purpose, return shape, and auth. However, it omits details about the structure of the 'preBuilt legs' and does not clarify the meaning of '5 for $25', leaving minor ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool accepts zero parameters, and the input schema is empty. According to the baseline for 0-param tools, a score of 4 is appropriate; the description further confirms no parameters are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as providing pre-priced '5 for $25' multi suggestions, with a specific scope of one pre-built multi per featured event. The 'Returns' line details the output structure, making the purpose unambiguous and distinct from other PointsBet tools such as racecards or in-play events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives is provided. The description mentions featured events but does not state selection criteria, intended use cases, or when to call other PointsBet tools like pointsbet_event or pointsbet_sport_featured_events.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_racing_formA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds useful behavior beyond that: 'Auth: none needed' and the return structure. There is no contradiction with annotations. The added info is helpful and accurate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: a one-sentence purpose, a return shape, an example, and an auth note. No fluff or redundant content; every sentence contributes useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description compensates by showing the return structure (RaceId, RaceNumber, RacePreview, RaceTips) and a full invocation example. This is sufficient for a simple read-only tool, though it omits potential error cases or richer response details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents all 5 parameters at 100% coverage. The description adds a concrete example with values like 'aus', 'sandown', '01', and '<today>-am', which helps illustrate the format and the date/session token pattern, but it does not add substantial semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Detailed form guide for one race' with the key contents (tips, predicted order, per-runner history). This distinguishes it from sibling tools like pointsbet_racing_tips (tips only) and pointsbet_racing_race (race info), and is reinforced by the returned structure.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The scope is clear: this tool is for a single race's form guide. However, it does not explicitly state when to use it over alternatives (e.g., pointsbet_racing_tips, pointsbet_racing_race) or provide exclusion criteria. Usage is implied rather than prescribed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_racing_tipsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnly, openWorld, and idempotent behavior. The description adds the exact return envelope (date, racingType, venue, tips), the grouping by venue, the 'today' time limit, and an 'Auth: none needed' note. This goes beyond the annotations without contradicting them, though it does not cover error behavior or link semantics.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence purpose, a return shape block, an example call, and an auth note. Each element earns its place, and the information is front-loaded for quick scanning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description supplies the full return structure and an example, which is essential. It also covers authentication and the temporal/grouping scope. Minor omissions like what the links contain or potential empty results exist, but for a simple read-only list tool, the description is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage: both 'racingType' (with enum) and 'country' are fully described. The description merely repeats these in prose and provides an example call, adding no new parameter-level meaning beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Tipster selections for a racing code + country for today, grouped by venue,' which clearly states the resource, scope, and grouping. The return shape and example further clarify it returns tipster, venue, and link data. This distinguishes it from sibling tools like pointsbet_racing_meetings or pointsbet_racing_race, which focus on meetings or race details rather than tipster picks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it (today's tipster selections for a racing code and country) and provides a concrete example, but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. There is no reference to sibling tools or a 'use this instead of X' statement, so the guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• polymarket_searchA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful context by stating the return structure and that no auth is required. However, there is a minor inconsistency: the description says it searches over 'events/markets/profiles' but the return key is 'tags' instead of 'markets', leaving the exact response composition slightly muddy. It also omits any mention of pagination or ordering, but with annotations present this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: the main purpose is in the first sentence, followed by the return structure and auth requirement. Every line adds value, there is no fluff, and it fits within a compact length appropriate for a search tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (3 parameters, no output schema), the description covers the essential aspects: what it does, what it returns, and authentication requirements. The return structure is explicitly listed, which is helpful in the absence of an output schema. The minor mismatch between searched entities and returned result keys slightly reduces completeness, but the overall context is sufficient for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema descriptions cover 100% of parameters (q, events_status, limit_per_type), each with a clear explanation. The description adds no extra parameter semantics beyond the schema, but that is acceptable given the high schema coverage. The baseline of 3 applies because the description does not need to compensate for missing documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Site-wide search') with a clear resource scope ('events/markets/profiles') and method ('free-text query'). This distinguishes it from sibling tools that fetch specific entities (e.g., polymarket_market, polymarket_events). The verb and subject are immediately actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you need to search across multiple entity types by free text, rather than retrieve a known item with a specific ID. It does not explicitly name alternatives or exclusion criteria, but the context of 'site-wide search' is sufficient for an agent to select it appropriately. No misleading guidance is present.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• polymarket_seriesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds value by disclosing 'Auth: none needed' and the return shape, which goes beyond annotations. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences with no fluff. It front-loads the core purpose in the first sentence and uses separate lines for return format and auth, making it highly scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-id tool with no output schema, the description covers the return structure, auth, and resource scope. It could mention error handling for invalid ids, but that is a minor gap given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 itself adds no additional meaning to the 'id' parameter beyond what the schema already states about it coming from polymarket_series_list or an event's series.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'One series by Gamma id, with its events' which clearly identifies the verb (retrieve), resource (series), and scope (includes events). It distinguishes itself from the sibling polymarket_series_list, which lists series, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you have a Gamma id, but it does not explicitly say when to use this vs alternatives like polymarket_series_list or polymarket_event. The schema describes the id source, but the description itself lacks explicit usage guidance or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_cms_pageA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly/openWorld/idempotent hints, and the description adds valuable context: auth is not needed, the return structure is shown, and the required-parameter constraint is explicit. This goes beyond what annotations provide without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, with the purpose stated in the first sentence, followed by a compact return type and auth note. No wasted words or redundant schema repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description appropriately includes a Returns line showing the page and blocks structure. It could be more complete by explaining behavior when both parameters are supplied or error handling, but for a simple read-only tool with three parameters, it provides sufficient context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds critical semantics by explicitly stating that one of competitionId or pagePath is required, which is not captured in the schema (since no required parameters are listed). This clarifies the mutual exclusivity beyond the schema's own 'use this OR' hints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves a CMS page block by either competition ID or page path, with a return shape included. It distinguishes itself from sibling CMS tools like sportsbet_cms_settings and sportsbet_cms_messages by focusing on page blocks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains that one of the two parameters is required, but provides no guidance on when to choose this tool over alternatives such as sportsbet_page_content or other CMS-related tools. It lacks explicit when-to-use vs. when-not-to-use instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_multiple_racecardsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly and idempotent annotations, the description discloses the return structure ({racecards:[{event:{}, markets:[]}]}) and explicitly states 'Auth: none needed.' These are additional behavioral details that aid the agent in understanding what to expect, though it doesn't cover rate limits or edge cases.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, front-loaded with the primary purpose, and efficiently provides the return shape and auth requirement in two short lines. Every sentence adds value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the single parameter and strong annotations, the description covers the essential aspects: purpose, return format, and auth. It does not fully elaborate on the structure inside event or markets, but it's reasonably complete for a batch retrieval tool of this simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides a 100% description coverage for eventIds, including 'Comma-separated racing event ids.' The tool description adds 'batch by event ids' which reinforces the purpose but doesn't clarify the array vs comma-separated discrepancy or add additional semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns racecards for multiple races in a single batched call, using 'several races in one call (batch by event ids).' This distinguishes it from single-racecard tools like sportsbet_racecard by emphasizing the batching capability.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'in one call' implies it is used when needing racecards for multiple events, but no explicit alternatives or exclusions are stated. It doesn't directly contrast with single-racecard tools or explain when not to use it, leaving usage guidelines merely implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_racecardA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the return shape, mentions 'scratchings' (indicating up-to-date data), and states 'Auth: none needed' – useful context not in annotations. This goes beyond the baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two sentences plus a JSON example and an auth note. It is front-loaded with the main purpose and every sentence contributes useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, read-only racecard lookup, the description provides the essential return structure and auth status. It does not mention error cases or how to obtain eventId, but the schema and annotations cover the primary needs, making this quite complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters have full descriptions in the schema (100% coverage), so the description does not need to repeat them. The description adds no parameter-specific detail beyond the schema, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Racecard for one race' with a specific verb+resource and scope. It distinguishes from sibling tools like sportsbet_multiple_racecards and sportsbet_racecard_with_context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for one race' implicitly indicates when to use the tool, but no explicit alternatives or when-not-to-use guidance is provided. Sibling tools are not referenced, leaving the agent to infer from the name that this is for a single race.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_racecard_with_contextA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context: the return structure ({event, markets, meeting, context}), an example call, and 'Auth: none needed.' This goes beyond the annotations and helps the agent understand expected behavior, though it does not cover rate limits or detailed error semantics.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: the first sentence states the purpose, followed by a return skeleton, example, and auth note. Every sentence earns its place, with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description compensates by providing a return structure skeleton (event, markets, meeting, context) and an example. It is adequate for a simple lookup tool, though it could mention how eventId/classId are obtained or what 'context' contains.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both eventId and classId. The description adds an example but no additional semantic meaning beyond the schema. Baseline of 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides 'Racecard plus surrounding context (meeting, results, related markets) for one race.' This is a specific verb+resource+scope that distinguishes it from sibling tools like sportsbet_racecard, which likely returns only the racecard without context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for a single race needing context, but does not explicitly state when to use this vs alternatives like sportsbet_racecard or sportsbet_multiple_racecards. There is no mention of when not to use it or which sibling to prefer for other scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_racing_best_betsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds value by disclosing the return structure ('Returns: {bestBets:...}') and authentication requirement ('Auth: none needed'), both beyond what annotations convey. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise and well-structured, with a brief purpose statement followed by 'Returns:' and 'Auth:' sections. Every sentence contributes meaningful information without redundancy, and the format is scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-output-schema tool with strong annotations, the description adequately covers purpose, return format, and authentication. It could potentially specify whether the best bets apply to current or upcoming races, but given the simplicity of the tool, the provided context is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and schema description coverage is 100% (empty schema). According to the rubric, the baseline is 4. The description adds no parameter-specific semantics but is not required to, given the absence of parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides 'Editorially-selected best bets across racing', identifying both the resource (best bets) and scope (racing). It distinguishes from sibling tools like sportsbet_racing_best_bets_with_events by focusing on the simple best bets list without event details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It does not mention that it should be used for editorial picks, nor does it point to other tools for more detailed event information or filtering. Only the tool's essence is stated, with no contextual comparison to siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_racing_best_bets_with_eventsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover the read-only, idempotent, and open-world nature, so the description adds value by specifying the exact return structure ({bestBets:[{event:{eventId, raceNumber}, selectionName, price:{winPrice}}]}) and stating 'Auth: none needed.' This goes beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two short sentences plus a return format block. The first sentence front-loads the core purpose, and every element provides useful information with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless tool with no output schema, the description gives a concrete return shape and auth note, covering the essential information an agent needs. It doesn't clarify what constitutes a 'best bet' or any implicit scope, but given the low complexity, this is largely sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the input schema carries no semantic weight. The description appropriately provides the return shape, which is sufficient given the lack of parameters, and the schema coverage is trivially 100%.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states it returns 'Best bets with their full parent event objects inlined', clearly specifying the resource (best bets) and the distinguishing feature (event objects inlined) relative to siblings like sportsbet_racing_best_bets. The action is implied by 'Returns', making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It doesn't name alternatives or suggest a context like 'use this when you need event object details', though the title and first line hint at this.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_sport_competitionA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already specify readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds 'Auth: none needed' and a clear return format, which goes beyond the annotations. No contradictions are present, though it does not disclose other behaviors like pagination, which is acceptable for a read-only page fetch.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise with two short sentences plus a return block. It front-loads the core purpose, then the return shape, then auth. Every sentence earns its place, with no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a rich input schema (all parameters described) and strong annotations. The description adds auth context and a return format, making it reasonably complete. It does not explicitly address the relationship to sibling tools like sportsbet_competition_matches, but the core functionality is well covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description lightly enriches parameters by mentioning 'matches, outrights' (mapping to eventFilter) and 'optional top markets' (mapping to includeTopMarkets), but it does not explain numMarkets or displayType further. Overall, the schema already documents each parameter adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Sport competition page: matches, outrights and optional top markets', which conveys the tool's function of retrieving a competition page with those components. It also provides a concrete return shape, making the purpose unambiguous and distinguishing it from sibling tools that likely focus on matches or outrights individually.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for fetching a competition page containing both matches and outrights, but it does not explicitly say when to use this tool versus alternatives like sportsbet_competition_matches or sportsbet_competition_outrights. There is no mention of when-not-to-use or exclusions, so the guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_sports_cardA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints, so the description only needs to add extra context. It does so by noting the dual behavior for live vs. resulted events and explicitly stating 'Auth: none needed', which goes beyond the structured annotations. This adds valuable insight without contradicting the hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is remarkably concise: two sentences plus a compact return shape. It front-loads the core purpose and includes only essential extras like the return format and auth requirement. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 6 parameters but no output schema, the description provides a helpful return shape and mentions the resulted-event behavior. It does not explain how the optional boolean include flags affect the output, but the schema descriptions cover those. The description is largely sufficient given the rich annotations and schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the input schema fully documents all 6 parameters. The description does not add any additional parameter semantics beyond what the schema already explains. The baseline of 3 applies because the description does not need to compensate for missing schema information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns a 'Full sport event card (all markets + selections)' and also covers resulted events. This distinguishes it from siblings like sportsbet_event_markets by emphasizing the 'full' scope. The verb 'Full sport event card' is specific and tied to the resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use for comprehensive event data but does not explicitly state when to choose this over alternatives like sportsbet_event_markets or sportsbet_sport_card_legacy. No exclusions or alternative recommendations are provided, leaving the agent to infer from the name and 'full' wording.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsdataio_nba_games_by_dateA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints, reducing the burden on the description. The description adds valuable context: the return shape is from vendor docs and unverified, advising the agent to inspect the actual payload, and it explains the auth key requirement. This goes beyond the structured hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with labels: purpose, return shape, caveat, example, and auth. Each section earns its place—the return field list is especially useful given the lack of an output schema. It is not overly verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool, this description covers all essential aspects: what it does, the approximate return object, an example call, authentication requirements, and a warning about unverified data. The caveat about the vendor docs is a significant additional detail that helps an agent avoid misinterpreting the response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, 'date', is fully described in the schema with format and required status, giving 100% coverage. The description's example JSON reinforces the format but does not add new semantic meaning beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource and scope: 'NBA games on a date, with the closing spread and total.' The 'Returns:' block confirms it is a retrieval operation with a specific payload. The sport-specific wording distinguishes it from sibling tools like sportsdataio_nhl_games_by_date.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or when-not-to-use guidance is provided, nor are alternatives mentioned (e.g., nba_scoreboard_today or balldontlie_nba_games). The example shows how to pass the date and the date format note is useful, but usage context is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsgameodds_playersA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it read-only/idempotent; description adds critical caveats: the return shape is unverified from vendor docs, no key is held, and auth is required via SPORTSGAMEODDS_API_KEY. This goes beyond the schema and annotations, though it doesn't cover rate limits 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately sized and structured: purpose, return shape, verification caveat, example, and auth. Each section adds value, though the JSON return shape block takes up space.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with no output schema, the description covers the essential return shape, a usage example, data-verification caveat, and auth requirement. It lacks notes on pagination or empty results, but the combination of annotations and description is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema descriptions are minimal ('Team id.', 'League id.', 'One player.'), but the description adds meaning by explaining playerID's relationship to oddIDs and providing a concrete example with values like 'BUFFALO_BILLS_NFL' and 'NFL'. This helps an agent understand format and usage beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies this as a tool for player data, linking playerIDs to prop oddIDs, and the return shape confirms it lists player objects. This distinguishes it from sibling sportsgameodds tools like teams or events, though it lacks an explicit verb like 'List' or 'Get'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides context that playerID is the statEntityID half of a prop's oddID, telling agents when to use this to resolve player info from props. The example with leagueID and teamID shows a concrete call pattern, but no explicit alternatives or exclusions are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• squiggle_standingsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds that no authentication is needed, that the returned data is actual (not projected), and provides the exact return structure. This is useful behavioral context beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a clear purpose statement, a return type listing, an example, and an auth note. Every sentence earns its place, with no redundancy or filler. The front-loaded purpose sentence makes the tool's function immediately obvious.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple standings tool, the description provides the return shape, an example, and auth status, making it largely self-sufficient. However, it does not specify behavior when year or round are omitted, nor does it explicitly differentiate from the sibling tool squiggle_ladder, leaving minor but non-critical gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with clear descriptions for q, year, and round, so the baseline is 3. The description adds a concrete example (q='standings', year=2026) that clarifies typical usage, but it does not explain the round parameter beyond what the schema already states. Thus it meets the baseline without substantial added value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'The ACTUAL AFL ladder — real wins/losses/percentage, not a projection,' which unambiguously states the tool returns real AFL standings and distinguishes it from projected ladders. The return structure further confirms the purpose. Though it lacks an explicit verb, the resource and differentiation are clear enough for a top score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'not a projection' implies this tool should be used when actual standings are needed, but no alternative tool is explicitly named. The example illustrates a typical call but does not provide explicit when-to-use vs. when-not-to-use guidance, leaving the agent to infer the intended usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_racing_meeting_racesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the description doesn't need to restate those. However, it adds behavioral details beyond annotations: it explicitly shows the output structure (races array with fields), provides a concrete example, and notes authentication requirements ('works without a key; TAB_CLIENT_ID or TAB_CLIENT_SECRET unlocks more if set'). This adds context about data shape and auth levels that annotations do not cover, enhancing transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and effectively structured: a one-line purpose, a returns section, an example, and an auth note. Every sentence adds value, with no filler or redundant information. It front-loads the core functionality and distributes supporting details logically. This is an exemplar of efficient description writing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that there is no output schema, the description compensates by explicitly stating the return structure (races with fields). It also provides an example that ties all parameters together and clarifies the expected usage. The authentication note adds completeness. However, it lacks details on possible edge cases (e.g., invalid venue, no races on that date) or pagination, but for a simple listing tool this is acceptable. Overall, the description is sufficiently complete for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for all four parameters, covering 100% of them (date, raceType, jurisdiction, venueMnemonic). The description's example demonstrates how to use these parameters (e.g., raceType 'R' for thoroughbred, venueMnemonic 'HAW' for Hawkesbury) but does not add new meaning beyond what the schema states. Since schema coverage is high, the description meets the baseline but does not elevate it; the example is a minor bonus.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: "The races for one meeting (by race type + venue code), each linking to its full racecard." It specifies the resource (races), the scope (one meeting), and the filtering criteria (race type + venue code). This distinguishes it from sibling tools like tab_racing_meetings (which likely lists meetings) and tab_racing_race (which likely retrieves a single race). The purpose is unambiguous and specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an example call and mentions the required parameters (date, raceType, venueMnemonic) but does not explicitly state when to use this tool versus alternatives. There is no mention of 'use this instead of tab_racing_meetings' or 'if you need individual race details, use tab_racing_race.' The usage context is implied but not explicitly contrasted with sibling tools. An example is helpful but doesn't equate to clear guidance on selection among similar tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_racing_next_to_goA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only/idempotent behavior; the description adds useful context: results are ordered by start time, each race links to its racecard, and auth behavior is disclosed (works without a key, with optional client credentials unlocking more). 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: a one-sentence purpose, a concise return shape, and an auth note. Every sentence adds value with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with no output schema, the description covers scope, ordering, return shape, and auth. Optional parameters are documented in the schema. Slight gap is the lack of explicit guidance against sibling racing tools, but this does not prevent correct use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the four optional parameters already have basic meaning. The description does not add parameter-specific semantics beyond the schema, so the baseline applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb+resource: lists races that are about to jump, across all codes, ordered by start time, with links to racecards. This distinguishes it from sibling tools like tab_racing_meeting_races or tab_racing_dates by scope and immediacy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The scope is implied by 'across all codes, ordered by start time,' which suggests use for imminent races globally. However, there is no explicit when-to-use versus alternatives, and no named sibling comparisons or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_recommendation_featuredA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds valuable behavioral context: the 404 when category isn't featured, the response shape, and the auth behavior (works without key, more with credentials). This goes beyond annotations and provides meaningful details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: purpose statement, error behavior, return format, example, and auth note each on separate lines. Every sentence adds value with no fluff. The front-loaded purpose and clear sections make it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with 2 parameters and no output schema, the description provides the return structure, example, error case, and auth details. It lacks mention of pagination or limits, but the tool's scope (featured items) suggests these may not be needed. Overall, it is sufficiently complete for expected use cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both parameters described in detail (including 'Pass raw spaces' and default for jurisdiction). The description's example usage adds a concrete invocation but doesn't introduce semantics beyond what the schema already provides. As per rubric, baseline is 3 when coverage is high.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Featured items for one recommendation category' with concrete examples (Jockey Challenge, Racing Extras). The 404 behavior and return structure further specify the tool's action and scope. While it doesn't explicitly contrast with siblings like tab_featured_events, the focused phrasing ('one recommendation category') differentiates it sufficiently.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by example (category parameter) and notes the 404 case, but it does not explicitly state when to use this tool versus alternatives or when not to use it. The auth note ('works without a key') is helpful but not a usage guideline relative to other tools. The guidance is adequate but not explicit about alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• theoddsapi_oddsA
  4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations by disclosing the exact return shape, clarifying that outcome `name` is a team name and `point` appears only on spreads/totals, and warning that the shape is from vendor documentation and has NOT been verified against a live response. It also notes quota cost behavior and the need for THE_ODDS_API_KEY, providing rich behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is fairly long but each section earns its place: purpose, quota warning, return shape, disclaimer, example, and auth note. The structure is clear with a returns block and note, though it could be slightly more concise by trimming redundant quota cost mentions already in the schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description fully details the return structure, clarifies tricky fields, provides a runnable example, warns about data reliability, and states authentication requirements. This is complete for a read-only, idempotent odds endpoint and leaves little ambiguity for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage with descriptions for all 7 parameters, including quota cost notes for `markets` and `regions`. The description repeats the quota cost warning and gives an example, but it does not add semantic meaning beyond what the schema already offers, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Odds for a competition across many bookmakers' and provides an example (EPL head-to-head across AU books), which makes its function evident. It does not explicitly differentiate itself from sibling tools like theoddsapi_event_odds, but the resource and scope (many bookmakers) are specific enough to distinguish it from events, scores, and historical odds.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives useful guidance on parameter usage (QUOTA COSTS markets × regions per call — keep both narrow) and an example invocation. However, it does not explicitly state when to use this tool over alternatives such as theoddsapi_event_odds or theoddsapi_scores, so the selection context is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_usersA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds valuable context: the batch limit of 100, the return format, and the required X_BEARER_TOKEN auth. This goes beyond annotations and helps the agent understand operational constraints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the main purpose, followed by return format and auth details. Every line provides necessary information without fluff, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of an output schema, the description explicitly states the return format and auth requirements, which is good. It covers purpose, limit, and operational details. However, it doesn't mention behavior for invalid or missing IDs, which is a minor gap for a batch lookup tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for both parameters (ids and user_fields), so the schema already provides the necessary semantics. The tool description re-states the 100-id limit but does not add new parameter details beyond the schema, resulting in a baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool performs a batch account lookup by numeric ids with a limit of 100. It specifically names the resource (accounts), the operation (lookup), and the scope (by numeric ids), which distinguishes it from sibling tools like twitter_users_by_usernames.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for numeric ID lookups but does not explicitly mention when to use this tool over alternatives like twitter_user_by_username or twitter_users_by_usernames. It provides a constraint (up to 100 ids) but lacks comparative guidance, so usage context is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_user_tweetsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the bar for additional transparency is lower. The description adds value by specifying auth requirements ('needs your own key in X_BEARER_TOKEN') and the exact return shape, including data fields and meta. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: three short sentences covering purpose, dependency, return format, and auth. Every sentence carries useful information, and no wasted words. The return example and auth note are clearly separated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an 8-parameter read-only tool with no output schema, the description provides the essential return structure, auth prerequisite, and a clear dependency flow. It does not mention rate limits or pagination behavior beyond the next_token field, but the schema covers parameter details, making this reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 parameters. The description adds no additional parameter details beyond hinting that the id must be resolved first, which the schema already indicates as 'Numeric user id.' With full schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states it returns 'An account's recent posts' with specific examples (club announcements, insider news). It uses a clear verb (get/list) and resource (account's recent posts), and the note to 'Resolve the id with twitter_user_by_username first' distinguishes it from other Twitter tools that might accept usernames or tweet IDs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear prerequisite ('Resolve the id with twitter_user_by_username first') which implies a usage flow. However, it does not explicitly contrast with sibling tools (e.g., twitter_tweets, twitter_search_recent) or say when NOT to use this tool. The context is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• unibet_kambi_live_statsA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, establishing the safety profile. The description adds valuable context beyond annotations by specifying the return shape ('Returns: {eventId, summary:{...live stats}}') and explicitly stating 'Auth: none needed,' which are not redundant with the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, with each line serving a purpose: the opening line states the core function, the 'Returns' line clarifies the output shape, and the 'Auth' line addresses a common concern. No filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description compensates by providing the return structure and noting that it includes scores and match summary. It also clarifies that no authentication is needed. However, it does not detail what fields are inside the summary or how lang/market parameters affect the response, leaving some ambiguity for a live-stats tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already documented in the input schema (e.g., eventId is described as 'Kambi event id (from a listView / betoffer call). Required — part of the URL path.'). The description itself does not add any new parameter-level detail beyond what the schema provides, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides 'Live in-event statistics (scores, match summary) for one Kambi event,' specifying both the resource (Kambi event) and the scope (single event). It distinguishes itself from siblings like unibet_kambi_odds_ladder by focusing on live stats rather than odds, and mentions the return structure explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by noting that eventId comes from 'a listView / betoffer call,' which tells the agent where to obtain the required input. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or competing tools in the same domain.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• unibet_racing_callA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide read-only, open-world, and idempotent hints. The description adds useful behavior beyond that: it explains the server-side hash mechanism and the meaning of PERSISTED_QUERY_NOT_FOUND (bundle drift), states that no auth is needed, and clarifies that race identifiers follow a specific eventKey format. These details help the agent anticipate errors and validate inputs.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tight and well-organized: a one-line purpose, a concise error-handling note, an example identifier, a pointer to the catalogue, then structured Returns/Auth lines. Every sentence adds information without fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a generic, open-ended tool, so a complete description cannot enumerate every operation. The description covers the endpoint, how to discover operations, error conditions, identifier format, and auth. Given strong annotations and 100% schema parameter coverage, this is sufficient contextual guidance. The absence of an output schema is compensated by noting the return is a JSON object, which varies by operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds marginal value by reinforcing the 'name + variables' pattern and pointing to a catalogue for variable signatures, which duplicates schema guidance. The example eventKey is useful, but it illustrates a value format rather than parameter semantics. No additional meaning beyond schema is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action: 'Call any of Unibet's persisted racing GraphQL operations' against a given endpoint. It identifies the resource (Unibet racing GraphQL), the method (by name + variables), and even provides an example eventKey format, distinguishing it from general sports GraphQL calls or other racing tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is the generic tool for any persisted racing operation, and points to 'unibet://racing/operations' for the operation list. However, it does not explicitly mention when to avoid this tool or use a dedicated racing sibling (e.g., tab_racing_race, sportsbet_racecard), so the guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wta_tournament_playersA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds useful behavioral context beyond annotations: 'Auth: none needed', the per-discipline event structure, and that final results (winner/runnerUp/eliminated) are included. It also clarifies that one event per discipline exists (LS, LD). 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is relatively concise but has some redundancy: the return structure is presented twice (once in the opening and again under 'Returns:'). It efficiently includes event type code definitions, an example, and auth note. The structure is front-loaded with the core purpose, and no unnecessary fluff is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two well-documented parameters and no output schema, the description is complete. It provides the full JSON return shape, explains event types, gives a concrete example call, and notes auth requirements. This is sufficient for an agent to select and invoke the tool correctly in most contexts.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both groupId and year already clearly documented including their roles and sources. The tool description adds an example call and reiterates that parameters are required part of the URL path, but it does not provide substantially new semantics beyond what the schema already offers. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's purpose as retrieving 'the entry list / draw for one tournament edition' and provides a detailed return structure including players, seeds, entry types, and final results. It distinguishes itself from sibling tools like wta_tournament_matches by focusing on the player entry list rather than match outcomes, aided by the explicit example of Australian Open 2025.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear context of what the tool does and includes an example request, implying when to use it (when needing tournament entry lists/seeds). However, it does not explicitly mention alternatives or when not to use this tool, so the usage guidance relies on inference rather than explicit direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_my_leaguesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint, openWorldHint, and idempotentHint annotations already indicate this is a safe, non-mutating lookup. The description meaningfully adds that it requires Yahoo authentication, that the response shape is from vendor documentation and is unverified, and that the payload shape should be inspected before relying on field names. This is strong added behavioral context for an agent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is fairly long, but the length is justified because there is no output schema and the nested return shape is needed. It is front-loaded with the core purpose, followed by structured sections: return shape, caveat, example, and auth. The vendor-documentation caveat is especially valuable and earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description supplies a detailed, caveated return-shape blueprint and an example call. It also covers authentication, the approximate nature of the payload, and the downstream use of league_key. This gives an agent enough context to call the tool, understand the response, and recognize when further verification is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers both parameters at 100% and explains gameKeys formatting, requiredness, and that bare codes mean the current season. The description adds a small example and clarifies the output is scoped to the authenticated user's leagues, but it does not materially enrich parameter semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies this as the endpoint for an authenticated user's leagues across one or more games, and emphasizes that it is the source of league_key. It distinguishes the tool by positioning league_key as the prerequisite for downstream league tools, which helps separate it from sibling tools like yahoo_my_games or yahoo_my_teams. A slight deduction because the opening is a noun phrase rather than an explicit verb ('retrieves', 'lists'), though 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states that league_key is what every league tool below needs, giving a clear workflow signal: call this first to obtain league keys. It also explains that gameKeys drives which games are included and provides a concrete NFL example. It does not explicitly discuss when to avoid this tool or name alternatives, but the downstream-hint is useful context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_broadcast_event_getA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds value by specifying the exact return shape and explicitly noting that no authentication is required. No contradictions with annotations exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded with the core action. The return format and auth note are useful, but the 'Also answers this' line is awkwardly phrased and could obscure rather than clarify; still, it remains compact and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only get-by-id tool with one documented parameter, the description provides the essential return fields and auth requirement. The output schema is absent, so the explicit return object helps fill that gap. Error behavior is not discussed, but overall the tool is adequately specified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes the only parameter, eventId, including that it is required and part of the URL path. The description does not add further parameter meaning beyond the phrase 'by id,' so the baseline 3 applies given 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear verb+resource+scope: 'Get a single broadcast event by id.' This distinguishes it from list-style sibling tools like afl_broadcast_events and from match-event-specific tools like afl_broadcast_match_events. The listed return fields reinforce the singular-event purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys use context by emphasizing 'single ... by id' and stating 'Auth: none needed.' It does not explicitly contrast with list alternatives, but the singular scope and alias list provide reasonable guidance. The 'Also answers this' line hints at overlap with other tools, though not as clearly as a direct alternative recommendation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_content_promo_listA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description doesn't need to re-state safety. It adds valuable context by specifying the exact return shape ({pageInfo, content:[{id, type:'promo', title, links:[{promoUrl, linkText}]}]}) and explicitly noting that authentication is not required ('Auth: none needed'). This goes beyond the annotations by describing the response structure and access requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: one clarifying sentence about the resource, a returns block, and an auth note. Every sentence adds value without redundancy. It is fully front-loaded with the purpose and gives essential technical details in a scannable format.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with 3 optional parameters and no output schema, the description provides enough context: purpose, return shape, and auth. The schema covers the parameters, so the description completes the picture by telling the caller what to expect in the response and that no auth is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage: all three parameters (limit, tagNames, referenceExpression) have descriptions. The tool description does not add extra parameter context, but the schema already provides sufficient meaning. Therefore, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'promo / marketing cards' and the action as 'List', which is specific and distinct from sibling tools like afl_content_promo_get, afl_content_text_list, and afl_content_video_list. The added detail about embedded CTAs (links[]) further clarifies what these cards contain.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving promo/marketing content, but does not explicitly state when to prefer it over alternatives or provide exclusions. There is no mention of when NOT to use this tool or what other tools might be better suited for different scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_matches_idmapA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful context beyond those hints: the payload size (~48 KB), the exact return structure, and the fact that no authentication is required. This is meaningful additional behavioral disclosure that helps set expectations for a read-only mapping operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, leading with the core purpose in the first line, then providing a clear return example and an auth note. Every sentence carries information, and the format is well-structured with 'Returns:' and 'Auth:' labels. There is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only mapping tool, the description is fully sufficient. It explains exactly what data is returned (including an example entry), the approximate size, and that no auth is needed. Combined with the annotations, the agent has all necessary context to invoke the tool correctly without an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so the description is not required to explain parameter meanings. With no parameters, a baseline of 4 is appropriate. The description does refer to 'every match providerId', which clarifies the scope of the mapping and the format of the keys (CD_M*), effectively adding semantic clarity that the schema cannot provide.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool maps every match providerId (CD_M*) to its integer id, which is a specific verb (map), specific resource (match providerIds), and the target distinction from sibling idmap tools like afl_teams_idmap and afl_players_idmap. The return format is also illustrated with a concrete example.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Although the description implies the tool should be used when a match providerId (CD_M*) needs to be converted to an integer id, it does not explicitly state when to use this versus alternative tools like afl_teams_idmap or afl_players_idmap, nor does it give any exclusions or prerequisite conditions. There is no direct usage guidance beyond the obvious mapping purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_match_getA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral context: score is only included 'when started', auth is 'none needed', and the matchId is explicitly 'NOT providerId'. These enrich understanding 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the verb+resource in the first sentence. It includes a clear return structure and auth note in two additional lines, with no unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple single-parameter tool, the description is fully complete: it explains the return payload, conditional score field, auth requirements, and the ID type distinction. The annotations cover safety and idempotency, so no additional context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema description already explains that matchId is the required URL path parameter and not providerId. The tool description adds no additional parameter semantics beyond restating 'integer id'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get a single match by integer id' with specific contents (teams, venue, time, score). This distinguishes it from sibling list tools like afl_matches_list and afl_matches_idmap, and the return shape is explicitly outlined.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The tool implies use when you have an integer match ID and need one match, but it does not explicitly contrast with alternatives such as afl_matches_list or afl_matches_idmap. No when-not-to-use guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_nfl_gamesA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context beyond that: the response shape is unverified from vendor docs and should be treated as approximate, the identity is wrapped under `game`, and an API key is required. This is a meaningful disclosure of uncertainty and prerequisites.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a clear one-line purpose, followed by a code-block response shape, relevant caveats, an example, and auth note. Each section earns its place; while somewhat long, it is well-structured and avoids redundancies.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a detailed (though unverified) response shape, an example query, and explicit caveats plus auth requirements. It lacks pagination and error details, but the core information an agent needs to invoke and parse this tool is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameter meanings are already documented. The description adds a concrete example ({"league": 1, "season": 2023}) demonstrating how to filter for a week of NFL games, which clarifies the use of league and season together beyond the basic field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches American-football games (NFL, NCAA) by date, season, or team. The resource and verb are explicit, and it naturally distinguishes from soccer or basketball siblings by naming the sport and leagues.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is an implied usage context (NFL/NCAA games) and a helpful example query, but no explicit comparison to alternative NFL/NCAA data sources like balldontlie_nfl_games or sportsdataio_nfl_scores. The note about the basketball/hockey hosts only addresses response shape, not when to choose this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_rugby_gamesA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context: the return shape is disclosed with field names, but explicitly warned as 'from the vendor's documentation' and 'NOT been verified against a live response,' advising to inspect actual payload. It also discloses the auth requirement (API_SPORTS_KEY) and provides an example payload shape. No contradictions 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately structured with sections: summary, return shape, NRL note, warning, example, and auth. It is somewhat lengthy but every section earns its place, especially given the important caveat about unverified response shape. The first sentence is a clear front-loaded purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description provides a return shape, a usage example, auth instructions, and a caution about unverified data. It does not describe pagination, sorting, or detailed error behavior, but for a simple read-only query tool with 4 optional parameters, the coverage is solid. The warning about unverified shape is a notable transparency addition.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description reinforces usage of 'date' and 'league' via the phrase 'by date or league' and a date example, but adds little for 'team' or 'season' beyond the schema's terse descriptions. It does not clarify how parameters combine or whether they are mutually exclusive.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: it retrieves rugby games by date or league, listing specific competitions (Six Nations, Super Rugby, NRL, Premiership). It also distinguishes itself with 'The catalogue's only rugby-union coverage,' making it unique among siblings. The action is implicit but unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context: 'The catalogue's only rugby-union coverage' implies when to use it. It explicitly advises using the 'keyless nrl provider' for NRL-specific needs, which is a when-not-to-use guidance. It also includes a concrete example, but does not exhaustively enumerate alternatives or state exact conditions for choosing between this and similar sports tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apitennis_eventsA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, open-world, and idempotent behavior. The description adds valuable context: it requires the user's own API key, and it explicitly warns that the response shape is from vendor docs and unverified against a live response, advising the agent to inspect the actual payload before relying on field names. This is strong transparency 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized: purpose, response shape, reliability warning, example, and auth. It is slightly longer than necessary but every section adds distinct value, especially the unverified shape warning and the example call.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one simple parameter and no output schema, the description is highly complete. It provides the expected return shape, an example invocation, auth requirements, and a reliability caveat. The agent has all necessary context to invoke the tool correctly and interpret the response cautiously.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, 'method', is fully described in the schema with 'Leave as-is.' and a default of 'get_events'. The description reinforces this by showing the example '{"method": "get_events"}' and the auth requirement, adding practical instruction beyond the schema's concise note.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'Event types the API covers' with examples like ATP singles and WTA doubles, and the returned shape confirms it lists event types. It lacks an explicit verb like 'list' or 'get', but the response shape and example make the purpose clear. It is distinguishable from siblings like apitennis_fixtures and apitennis_livescore which cover different resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: call this tool when you need the event types the API supports, and the example shows the method to use. However, it does not explicitly state when to use this over sibling tools like apitennis_fixtures or provide any exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apitennis_h2hA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description significantly extends beyond the annotations. It discloses that the return shape is from vendor docs and unverified, warns to treat it as approximate, highlights that `result` is an object rather than a list like other methods, and specifies the authentication requirement. These are valuable behavioral traits not covered by readOnlyHint, openWorldHint, or idempotentHint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear opening sentence, return shape, caveat, example, and auth note. It is slightly verbose due to the vendor-doc warning, but every sentence serves a purpose. The important caveats are prominently placed, and the overall length is acceptable for the amount of critical information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of an output schema, the description provides a rough return structure with caveats about its accuracy, which is essential. It also includes an example and auth requirements. However, it does not cover error cases, pagination, or data freshness beyond the unverified note, which would make it more complete. For a relatively simple tool, it is fairly thorough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% parameter coverage with descriptions for method, first_player_key, and second_player_key. The description adds an example with concrete key values and notes the default method, but does not significantly deepen understanding beyond the schema. Thus the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'Head-to-head history between two players, plus each one's recent form,' which is a specific verb+resource combination. It clearly distinguishes itself from sibling tools like apitennis_events, apitennis_fixtures, etc., by specifying the H2H nature and the inclusion of recent form.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case (H2H history) but does not explicitly state when to use this tool vs alternatives. It provides an example but no direct comparison or exclusion of other tennis tools. The purpose clarity partially compensates, but explicit guidance on when to choose this over siblings is missing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apitennis_playersA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds valuable context beyond the annotations by disclosing that the return shape is unverified from vendor docs and should be treated as approximate. It also mentions the need for an API key in API_TENNIS_KEY. These caveats help set expectations for reliability. The description does not contradict the readOnlyHint or idempotentHint annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the purpose and then includes the return shape, an important caveat, an example, and auth instructions. The return shape is lengthy but necessary because there is no output schema. No words are wasted, and the structure is logical.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-player lookup with two parameters, the description covers the key aspects: return shape, example usage, auth requirements, and a warning about unverified data. Since there is no output schema, including the approximate shape is helpful. It does not mention error handling or edge cases, but that is not critical for this tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for both parameters: method 'Leave as-is' and player_key 'Player key (from fixtures or standings).' The description adds an example invocation but no new parameter semantics beyond what the schema provides. Given the high schema coverage, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'One player's profile and recent results' which identifies both the resource (player) and the scope (single player, profile + results). The example uses method 'get_players' and a player_key, reinforcing the tool's purpose. This distinguishes it from sibling tools like apitennis_standings or apitennis_h2h.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool should be used when you need a single player's profile and recent results, and the example clarifies the required parameters. However, it does not explicitly mention alternatives or when not to use it, such as noting that apitennis_standings would be better for rankings. This is clear context without exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apitennis_tournamentsA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the read-only/idempotent annotations, the description discloses the auth requirement (API_TENNIS_KEY) and explicitly warns that the return shape is from vendor docs and unverified against a live response, advising the agent to inspect the actual payload. This is valuable behavioral context not present in annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tight and front-loaded with the purpose, then includes return shape, caveat, example, and auth. The only minor inefficiency is the example duplicating the schema default, but overall every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a simple list operation with no output schema, so the description correctly provides the return shape and a caveat about data reliability. It covers auth and example usage. It doesn't explain field semantics, but those are straightforward from names, and the unverified shape warning is appropriately included.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline 3 applies. The description adds little beyond the schema: it restates the optional event type filter and shows an example with method 'get_tournaments'. The schema already documents both parameters adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies the resource as 'Tournaments' and mentions the optional event type filter, making the purpose reasonably clear. However, it lacks a specific verb like 'list' or 'get' and does not differentiate from sibling tools such as wta_tournaments. The example method 'get_tournaments' clarifies intent but is not part of the core purpose statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete example of fetching all tournaments and notes the optional event_type_key filter, with a cross-reference to apitennis_events in the schema. It does not explicitly state when not to use this tool or name alternatives, but the context is clear for a simple list operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_event_typesA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond annotations by stating 'Auth: none needed' and providing the return structure with field names. While annotations already indicate read-only and idempotent behavior, the additional auth and return format details enhance transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is concise and front-loaded with the core purpose. The Returns and Auth lines are additional useful details, and every sentence earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple no-parameter lookup tool, this description is complete. It states what is included, the return field structure, and auth requirements. Annotations provide safety hints, and no output schema exists, so the included return description compensates well.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Tool has zero parameters, so schema coverage is vacuously 100%. Baseline for 0 params is 4, and description does not need to add parameter semantics. It does describe the output fields, which is helpful.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides all event types (sports + racing) with event counts and SGM availability. It uses a specific resource ('event types') and scope, distinguishing it from sibling tools like betr_master_category or betr_sports_category.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives. There is no mention of alternatives or exclusions, though the simplicity of a no-parameter lookup tool makes the use case somewhat self-evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_fav4A
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context: 'Auth: none needed' and the exact return structure. It does not contradict annotations and provides extra behavioral details (return fields) that annotations do not cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, with a clear one-line purpose followed by the return shape and auth requirement. Every sentence provides distinct information, and there is no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple read-only list tool with one optional parameter. The schema fully describes the parameter, and the description provides the return structure in lieu of an output schema. It also covers auth, making the tool's behavior sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully documents the single parameter EventTypeFilter with description 'Race-type filter (7 = all racing)' (100% coverage). The description's phrase 'for a race-type filter' adds no new meaning beyond the schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Returns') and resource ('Featured 'Fav 4' upcoming races') with a scoping parameter ('for a race-type filter'). It clearly distinguishes from sibling tools like betr_next5_races and betr_todays_races by focusing on the 'Fav 4' subset.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving featured Fav 4 races by race type, but does not explicitly state when to use this tool versus alternatives such as betr_next5_races or betr_todays_races. There are no when-not-to-use instructions or alternative tool names.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_master_eventA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral context: 'Auth: none needed,' the full response structure, and the fact that each call returns only one market group. This goes beyond annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, starting with the core purpose, followed by a compact return schema, and ending with auth info. The Returns block is somewhat detailed but valuable given no output schema, and every element earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the inline Returns block fully specifies the response shape, and the description covers the input source, group selection, and auth. It omits deep field semantics but is complete for a straightforward read-only tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already explains both parameters well. The description adds minimal extra parameter context (e.g., how MasterEventId is obtained and that GroupLinks drives follow-up calls), but the schema carries the main load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's purpose: retrieving one sport match's markets by master event ID, with a specific market-group-per-call design. It distinguishes itself from siblings by emphasizing the GroupLinks mechanism and the nested Events[].Outcomes[] structure.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear context on when to use the tool (with a master event ID from a category/SGM feed) and how to navigate market groups (optional GroupTypeCode, default group). It lacks explicit exclusions or naming of alternative sibling tools, but the usage context is solid.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_raceA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral context beyond these: 'results once run' indicates data changes over time, and 'Auth: none needed' clarifies access requirements. It also briefly exposes the return structure, which aids transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: first sentence states the tool's purpose, followed by a brief return-type sketch and an auth note. Every sentence carries useful information, with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only single-parameter tool with strong annotations, the description is complete: it identifies the input source, lists the return content (runners, prices, bet types, results), shows a partial return structure, and states auth requirements. No output schema exists, but the return sketch covers the essentials.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for the single `eventId` parameter, including its source ('from a races feed'). The description does not add further parameter semantics beyond mentioning EventId in the return type, so it provides no additional value over the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides a 'Full racecard for one race: runners, prices, allowed bet types, results once run.' This is a specific resource (racecard) and explicitly differentiates from sibling tools like betr_grouped_racecard by emphasizing 'one race' and listing concrete content.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied by the description: use this for a single race's full racecard. However, there is no explicit 'when to use vs. alternatives' guidance, such as 'for multiple races use betr_grouped_racecard' or 'for form use betr_race_form.' The single-race scope is clear but no alternatives are named.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_race_flucsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description supplements these with 'Auth: none needed' and an explicit return structure, adding useful behavioral context without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely compact: a one-line purpose, a one-line return shape, and a one-line auth note. Every line is informative and front-loaded, with no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only tool, the description is self-sufficient: it explains what is retrieved, the per-runner/per-race scope, the exact return shape (Items/OutcomeId/Flucs/Offset/Price), and auth requirements. Since there is no output schema, the explicitly documented return structure is essential and fully provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the sole parameter 'EventId' with 'Race event id,' and coverage is 100%. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description specifies a clear resource and scope: 'Price fluctuation history per runner for one race (fixed-odds movements).' It distinguishes itself from broader racing tools by focusing on per-runner, per-race fluctuation history, though it lacks an explicit action verb like 'Get' or 'List.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies the use case by specifying the data scope: per-runner price fluctuation history for one race, so an agent can infer when to call it. However, it does not explicitly name alternatives or provide when-not-to-use guidance, stopping short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfbd_portalA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, idempotentHint), the description adds valuable caveats: the return shape is unverified and sourced from vendor docs, advising the agent to inspect the actual payload. It also discloses the auth requirement (CFBD_API_KEY), which annotations do not cover. This is exemplary transparency for a tool with no live verification.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized and front-loaded with a clear summary, followed by return shape, critical caveat, example, and auth note. Each section earns its place; the length is justified by the need to warn about unverified data and auth requirements. It is not bloated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool, the description is remarkably complete: it gives the return shape, an example invocation, authentication details, and a warning about data reliability. With no output schema and a low-complexity tool, the description covers all essential aspects for correct invocation and result interpretation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the 'year' parameter with baseline coverage. The description adds a concrete example (2024 portal -> {"year": 2024}), which clarifies how to pass the value. This enriches the param semantics beyond the schema's simple 'Season year.'

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning transfer-portal moves for a season, with origin, destination, and rating. The scope and domain are specific, and it stands apart from sibling tools like cfbd_games or cfbd_teams. However, it lacks an explicit verb (e.g., 'get' or 'list'), relying on a noun phrase and example to convey the action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you need transfer-portal moves for a specific season. It provides an example call but does not state when not to use it or mention alternative tools (e.g., other CFBD endpoints). There are no explicit exclusions or alternative comparisons.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfbd_ratings_eloA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint and idempotentHint annotations, the description adds important behavioral context: the response shape is from vendor documentation and unverified, requiring the agent to inspect the actual payload before trusting field names. It also discloses the authentication requirement (CFBD_API_KEY). These are valuable caveats.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured, with a clear one-line purpose, a return shape, a necessary caveat about unverified data, a concrete example, and auth instructions. Every sentence earns its place, and the most critical information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the return shape and includes an example, but it does not explain behavior when no filters are provided, how parameters combine, or what each parameter's permitted values are beyond the schema. The unverified shape warning is helpful, but for a 4-parameter tool with no output schema, more detail on default behavior and parameter combinations would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers all four parameters with descriptions (100% coverage), giving a baseline of 3. The description's example ({"year": 2024}) provides a practical usage illustration, and the return shape hints at the conference and team parameters. It adds some context beyond the schema, but does not fully explain parameter constraints or interactions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as providing Elo ratings filterable by team and week, distinguishing it from sibling rating tools like cfbd_ratings_sp and cfbd_rankings. The verb 'Returns' and specific resource 'Elo ratings' make the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is provided on when to use this tool versus alternatives like cfbd_ratings_sp. The example shows a valid call but does not state when this tool is preferred, what filters are required, or how it differs from similar rating/ranking tools. Usage is implied rather than directly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfbd_ratings_spA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds substantial context beyond the annotations: it warns that the return shape is unverified and approximate due to lack of a live key, advises inspecting the actual payload, notes that defensive ratings are better when lower, and discloses the API key requirement. These are important behavioral traits that an agent must know to use the tool safely and interpret results correctly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the core purpose, followed by a return shape, a critical caveat, an example, and auth info. Each section earns its place, though it is slightly longer than necessary. The unverified-shape note is essential, and the example is compact.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description compensates by providing an inline return shape and an example. It also covers auth and a key interpretive note. However, it does not clarify what happens when both optional parameters are omitted or when 'team' is provided, and it leaves some return field semantics (e.g., success, explosiveness) unexplained. Overall, it provides enough context for a safe initial call but has minor gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes both parameters ('team' and 'year') with 100% coverage. The description only provides an example using 'year' and does not add new semantics about how team filtering behaves or whether parameters are combinable. It adds minimal value beyond the schema, so it stays at the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this tool returns SP+ ratings, a specific predictive rating system for college football, split by offense and defense. This distinguishes it from sibling cfbd_ratings_elo (which covers Elo ratings) and other CFBD tools. The verb 'returns' and resource 'SP+ ratings' are explicit and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for SP+ ratings specifically, and the example shows a typical use case (year-only query). However, it does not explicitly mention when to use this instead of cfbd_ratings_elo or other rating tools, nor does it state exclusions or prerequisites beyond requiring an API key. The usage context is implicit rather than directly contrasted with alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketaustralia_venueA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint, idempotentHint, openWorldHint) already establish the safety profile. The description adds valuable context beyond that: the exact return shape ({venue:{...}, responseError}), which compensates for the absent output schema, and the auth requirement ('Auth: none needed'). 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: a purpose sentence, a usage note, a Returns line, and an Auth line. Every section earns its place, and the structure front-loads the core purpose before supporting details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool with one required parameter, the description is largely complete: it documents parameters (via schema), return shape (via Returns line), and auth. Minor gaps remain, such as not explaining when responseError is populated, but the overall package is sufficient for correct tool invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — all three parameters (venueId, format, jsconfig) are documented in the schema itself. The description adds minimal extra meaning ('one venue per call'), so the baseline of 3 is appropriate; the schema carries the parameter documentation burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb-resource pair ('Venue detail for one venueId') and enumerates the returned fields (name, city, country, state, coordinates), making the tool's scope unmistakable. It also distinguishes itself from sibling tools like cricketaustralia_fixtures by stating it resolves a fixture's venueId one venue at a time.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  'Resolve a fixture's venueId (one venue per call)' provides clear context for when to use this tool — after obtaining a venueId from fixture data — and implies a single-venue-per-call pattern. It does not explicitly name alternatives or exclusions, but the guidance is sufficiently contextual.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketdata_matchesA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations by disclosing pagination behavior, the exact return shape, and a critical caveat that the shape is unverified from vendor docs. It also explains the authentication requirement (CRICKETDATA_API_KEY). This is exceptionally transparent for an unverified vendor integration.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the main purpose, then provides return shape, caveat, example, and auth info. While the caveat adds length, it is essential for transparency. The 'Example: Recent matches' section is more of a heading than a real example, slightly reducing structure clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list endpoint with one optional parameter, the description covers the key aspects: scope, pagination, return shape, auth, and reliability caveat. It is complete enough for an agent to invoke the tool correctly, though it lacks explicit field descriptions (mitigated by the output shape being listed).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, offset, is fully described in the input schema as 'Page offset (25 per page)'. The description adds no further detail about the parameter, so it relies on the schema which already covers it. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'All matches, paginated — recent and upcoming across every series', specifying a concrete verb and resource. This distinguishes it from sibling tools like cricketdata_current_matches, which presumably returns only current matches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving all matches and mentions pagination, but does not explicitly contrast with alternatives such as cricketdata_current_matches or state when not to use this tool. Usage is inferred rather than explicitly guided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_approach_skillA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only and idempotent hints, so the description adds extra value by specifying the auth requirement (DATAGOLF_KEY) and the exact return structure. It could mention rate limits or filtering limitations, but the provided context is meaningful enough to warrant a 4.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is succinct, front-loaded with purpose, and structured into a main sentence plus Returns and Auth sections. Every sentence offers functional value with no waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite not having an output schema, the description provides the return shape and critical auth context. With good annotations and only two optional parameters, this is a complete and self-sufficient description for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters (period, file_format) having clear descriptions and enums. The description does not add further param details, but the schema already carries the burden. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource ('approach-play skill per player') and the specific metrics (SG per shot, proximity, GIR, rates). 'Detailed' adds specificity. While it doesn't explicitly distinguish from siblings, the niche focus is enough to differentiate it from tools like datagolf_skill_ratings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its use case through the metric details, but it offers no explicit 'use this when' guidance or mention of alternatives like datagolf_player_decompositions. This is an implied usage scenario, not a clear directive with exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entain_metadata_by_urlA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool read-only, open-world, and idempotent. The description adds the return format and clarifies that an empty object is returned when no override exists, plus that no authentication is needed, providing useful behavioral context beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, with two lines covering purpose, return format, empty behavior, and auth. All information is front-loaded and every element adds value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter tool, the description completely covers the return shape, the empty case, and auth requirements. The annotations handle safety and idempotency, and the schema covers the parameter, so no gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully documents the url parameter with an example, and the description also mentions it's a URL path. With 100% schema coverage, the description adds little additional semantic value, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns SEO metadata (page title) for a URL path, specifying both the resource and scope. It distinguishes itself from sibling tools by focusing on metadata lookup by URL path, and the intent is unambiguous despite the absence of an explicit verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving page title metadata but gives no explicit when-to-use guidance or alternatives. It does not mention exclusions or comparisons with sibling tools, so the agent gets minimal context for selection among many similar metadata tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entitysport_matchesA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the agent knows it's a safe read. The description adds significant transparency: it discloses the response shape is from vendor docs and unverified, clarifies the distinction between scores_full and scores, and states the auth key requirement. These go well 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with line breaks separating the summary, return shape, caveat, example, and auth. The return shape is detailed but necessary given no output schema. Each section serves a purpose, though the overall length is above average.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description provides a full return shape, an authenticity caveat, a status example, and auth requirements. It covers all relevant aspects of using the tool, including the unverified nature of the payload, which is important for an agent to handle appropriately.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions (date, paged, status, per_page). The description adds only an example using status=3, which reinforces the schema but doesn't add new meaning beyond what's already documented. Per the baseline, a score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Cricket matches — live, upcoming and completed', which clearly identifies the resource and the three match states. The return shape listing 'items' confirms it returns a collection. However, it lacks an explicit verb like 'List' or 'Fetch', and does not directly mention alternative tools for per-match details, so it doesn't fully distinguish from sibling entitysport tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example 'Live matches {"status": 3}' provides concrete guidance on how to request live matches, and the auth note tells the agent it needs ENTITYSPORT_TOKEN. The schema's status descriptions also contextualize usage. However, it doesn't explicitly state when to use this tool instead of entitysport_match_info/scorecard/commentary, nor any exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entitysport_match_scorecardA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds critical transparency: the response shape is from vendor documentation and NOT verified against a live response, warning agents to inspect the actual payload. It also discloses the authentication requirement (ENTITYSPORT_TOKEN). These are valuable behavioral insights that annotations do not cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and efficient: a one-sentence purpose, a compact return-shape block, a clear caveat about unverified data, an example, and an auth note. Every sentence carries necessary information with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description takes on the full burden of explaining the return structure, which it does in detail (innings, batsmen, bowlers, extras, equations, fows, did_not_bat). It also includes the important caveat that the shape is approximate and the auth requirement, making it complete for an agent to invoke correctly and set expectations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes matchId with type and required status, and the description merely adds an example value (12345). With schema description coverage at 100%, the description adds minimal new parameter semantics, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Full innings-by-innings scorecard,' which clearly identifies the tool's specific function and resource. It distinguishes itself from sibling tools like entitysport_match_info and entitysport_match_commentary by emphasizing the detailed inning-by-inning breakdown with batting and bowling statistics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives among the siblings. It does not state when to prefer this over entitysport_match_info or entitysport_match_commentary, nor does it mention any exclusions or prerequisites beyond the auth note. The example shows a call but does not help select the tool contextually.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_league_defaultsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety traits. The description adds useful behavioral context: it works without a key, optional cookie unlocks more, and it describes expected return structure. It does not contradict annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with sections for returns, example, auth, and related tools. It is slightly verbose with the 'Also answers this:' line, but each part earns its place. It could be trimmed, but overall it is readable and front-loaded with the main purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with 3 well-documented params and no output schema, the description provides sufficient context: return shape, example, auth note, and related tools. The schema covers scoringTypeId edge cases. No major gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and each parameter already has a detailed description, including valid enums and the meaning of scoringTypeId values (1=Standard, 3=PPR, etc.). The description adds an example but otherwise relies on the schema, which is appropriate given the high coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it retrieves ESPN's stock league templates (scoring/roster presets) based on scoring-type id. It distinguishes itself from sibling tools by explicitly mentioning 'fpl_game_rules, sleeper_league, yahoo_league_settings' and includes a concrete example of a PPR preset request.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains the tool's purpose (defaults for a new league) and provides an example invocation. It hints at alternatives by mentioning similar tools, but does not explicitly state when to use this tool instead of others or when not to use it. This is clear enough but lacks explicit exclusionary guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_league_settingsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable non-obvious behavioral details: auth works without a key but ESPN_FANTASY_COOKIE unlocks more, and responses include a 'status' field alongside settings. No contradiction with annotations, and the added auth nuance exceeds the baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is organized with labels (Returns, Example, Auth, Also answers) and each section contributes useful information. The only slight issue is the cryptic 'Also answers this:' phrasing, which requires inference; otherwise the length and structure are appropriate for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a settings-retrieval tool with no output schema, the description provides a fairly detailed return structure, an example, auth behavior, and cross-tool fit. It could mention error cases (e.g., invalid leagueId) or season constraints (>= 2018 is in schema), but overall it covers the key aspects an agent needs to invoke it confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% — every parameter has a description, so the schema carries the parameter semantics. The description adds an example invocation and hints at use cases, but does not elaborate on parameter meanings or interactions beyond what the schema already gives. This matches the baseline of 3 for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as league settings/rules and enumerates specific content areas (name, size, scoring, roster, schedule/playoff, waiver/keeper/trade). It also provides a return structure and example, making the tool's function unmistakable even without a leading verb. The closing line about fpl_game_rules, sleeper_league, and yahoo_league_settings helps distinguish it from sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit context on when it works ('works without a key') and mentions alternative/sibling resources ('Also answers this: fpl_game_rules, sleeper_league, yahoo_league_settings'), helping the agent infer substitution scenarios. However, it does not explicitly state 'use when you need X, otherwise use Y' with crisp when-not conditions, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_navA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the read-only, idempotent, and open-world annotations, the description adds useful context: it works without a key, and an optional cookie unlocks more data. It also discloses the payload's lightweight nature and the return structure, which is consistent with 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally compact and front-loaded with the core purpose, followed by return shape, an example, and auth note. Every sentence serves a clear function with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description compensates by listing key return fields and providing an example. It covers auth, intended use, and request shape, though the 'status:{…}' abbreviation leaves some detail unspecified, which is acceptable for an orientation endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of parameters, so the baseline is 3. The description adds meaningful value with a concrete example request including game, seasonId, and leagueId, illustrating how to form a valid call.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns a lightweight nav payload with league name, size, and the current user's team, for cheap orientation before a heavy call. It lists return fields and an example, making the purpose unmistakable, though it lacks an explicit verb like 'get'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly positions this as a cheap pre-call orientation tool, providing clear usage context. However, it does not name specific sibling alternatives or state when not to use it, so it falls just short of full exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espn_teamsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description needs less disclosure. It adds the return structure and auth requirements, which is useful. However, there is an inconsistency: it claims 'colours and logos' are included but the return structure only shows id, displayName, abbreviation. This minor contradiction in the description reduces trust in behavioral transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with purpose, usage, return structure, example, and auth note. It is concise but covers all essential aspects. The inclusion of both a return structure and example is valuable, though the discrepancy about colours/logos adds a minor blip, preventing a perfect score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of an output schema, the description compensates nicely by showing the return structure and an example. It also mentions auth and usage context. The only gap is the inconsistent mention of fields (colours/logos vs. the return structure), which leaves a small ambiguity about the exact response shape.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers both parameters with descriptive text (sport and league slugs). The description adds a concrete example ({'sport': 'football', 'league': 'nfl'}) and the phrase 'for one league' reinforcing the league parameter. This goes beyond the schema by providing a clear, valid input pair, so it earns a 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Team catalogue for one league' and lists the specific fields (id, name, abbreviation, colours, logos). This is a specific verb+resource pair that distinguishes it from sibling tools like pl_teams or mlb_teams, and the reference to using team ids with espn_site_call clarifies its role in the ESPN ecosystem.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says 'Use the team ids with espn_site_call (team_roster, team_schedule, …)' which tells the agent when to use this tool. It also provides an example input. However, it does not state when not to use it or mention alternatives, so it falls short of the explicit when/when-not/alternatives bar for a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• euroleague_seasonsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the return shape ({total, data:[...]}), notes that no authentication is needed, and provides a concrete example — all beyond what the annotations (readOnlyHint, openWorldHint, idempotentHint) already convey. It doesn't discuss rate limits or pagination, but for a simple read-only season list, the added context is meaningful.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, followed by a useful return-shape block, an example, and a brief auth note. Each section earns its place; the structure is cleanly organized, though slightly segmented.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one optional parameter and strong annotations, the description covers the essentials: purpose, return shape (compensating for the absent output schema), an example, and auth requirements. No critical gaps stand out for this low-complexity tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (the enum parameter is fully described with 'E = EuroLeague, U = EuroCup'), so the baseline is 3. The description's example call ({'competition': 'E'}) reinforces usage but adds no new semantic meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb and resource: 'call this to get valid season codes like E2024.' It distinguishes itself from sibling tools like euroleague_games or euroleague_rounds, which handle games and rounds rather than season metadata.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly directs the agent to use this tool when it needs valid season codes, providing a concrete trigger ('call this to get valid season codes like E2024'). It doesn't name alternatives or exclusions, but the clear use-case phrasing gives sufficient contextual guidance for a simple lookup tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• footballdataorg_scorersA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint. The description adds a key requirement (403 without) and a caveat that the return shape is from vendor docs and unverified. This provides valuable context beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with the core purpose first, followed by return shape, caveat, example, and auth. The auth requirement is mentioned twice, which is slightly redundant, but the overall organization is efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with no output schema, the description covers purpose, auth, return shape, and an example. It lacks explicit alternative guidance but is otherwise complete enough for safe invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with all parameters described. The description's example ('competition: PL', 'limit: 10') is illustrative but does not add new semantic meaning beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Top scorers in a competition', specifying the resource and scope. It distinguishes from sibling tools like standings or matches. The example reinforces the intended use.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: use when needing top scorers for a competition. It also notes the auth prerequisite. However, it does not explicitly mention when not to use or name alternatives like footballdataorg_standings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• footballdataorg_teamA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds value by disclosing the auth requirement (403 without key) and honestly noting that the return shape is unverified and approximate, advising the agent to inspect the live payload. This goes beyond the annotations and sets accurate expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose and then provides necessary details in a structured way: auth, return shape, caveat, example, and auth again. Each line earns its place, though the return shape block is lengthy and the auth note appears twice, making it slightly less concise than ideal.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple team lookup with no output schema, the description compensates by listing the exact return fields, providing an example, and flagging the unverified shape. The auth requirement is also critical for successful invocation. It is largely complete, though it could mention that the teamId should come from the teams list (already in schema) and lacks any note about expected data freshness or pagination (unlikely needed here).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for the single parameter teamId, already describing it as the team id from footballdataorg_teams and part of the URL path. The description adds a concrete example with teamId 57 but does not provide substantial extra semantic detail beyond the schema. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: returns one club with its squad and running competitions. The phrase 'One club' distinguishes it from the plural 'footballdataorg_teams' sibling, and the example with teamId reinforces the singular fetch. This is a specific verb+resource with clear scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides important usage context: it requires a key (403 without), and the example shows how to call it. It implies when to use it (getting a single team) versus listing teams, though it does not explicitly name an alternative tool. The auth requirement is a clear prerequisite.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• formulae_raceA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, open-world, and idempotent hints. The description adds valuable behavioral context: 'Auth: none needed' and the limitation 'there is no results payload on this host,' plus the presence of hasRaceResults/hasSessionResults flags. This goes beyond what annotations provide, though it could be more explicit about 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and covers purpose, return fields, an example, and auth in four short sections. The example formatting is a bit ambiguous (it looks like an input payload but is presented as an example), and the 'see the docs' reference is vague, but there is no unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only tool with good annotations, this description is fairly complete: it explains the return shape, the absence of results payload, and authentication. It could mention how to obtain the raceId (though the schema implies it comes from formulae_races), but overall it provides enough context for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for the single parameter raceId, including the description 'Race uuid from formulae_races. Required — part of the URL path.' The description adds an example but no additional semantic meaning beyond the schema, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'One race's detail: circuit, city, date and whether results exist,' which clearly identifies the tool as a detail/retrieval endpoint for a single race. It lists the specific resource (race) and differentiates from the plural sibling formulae_races by emphasizing 'One race's detail.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: to get race metadata and existence flags. It explicitly notes 'there is no results payload on this host,' implicitly telling the agent not to use this tool for race results. However, it does not name specific alternative tools for results or for listing races, relying on the schema reference to formulae_races.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• formulae_racesA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, open-world, and idempotent hints. The description adds value by disclosing the exact return shape (pageInfo and races array with fields), the fact that it is wrapped, an example request, and auth requirements. This goes beyond the structured safety hints without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is organized into a short title line, a returns block, an example, and an auth note. Every section is purposeful and no word is wasted. It is slightly longer than the two-sentence ideal but remains scannable and relevant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter list tool, the description is quite complete: it covers scope, return fields, an example, and auth. The pageInfo field hints at pagination but omits how to fetch additional pages; however, the schema and annotations are rich enough that this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with 'Championship uuid. Omit for every race across all seasons.' The description restates this concept and adds a concrete UUID example, but it does not add significant new meaning beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific resource: 'The race calendar — all seasons, or one championship's rounds.' It clearly states the tool returns races and distinguishes it from sibling tools like formulae_standings by noting the response is 'WRAPPED, unlike standings.' The scope (all seasons vs. one championship) is explicit, making it easy to select over a single-race tool like formulae_race.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is conveyed through the optional championshipId parameter: 'Omit for every race across all seasons' and an example of filtering to one season. It also states 'Auth: none needed.' However, there is no explicit mention of when to prefer this over a sibling like formulae_race, so it slightly misses the 'alternatives' bar.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_live_gameweekA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the tool as read-only and idempotent; the description adds valuable behavior: the returned JSON structure, the meaning of `explain` for reconciling scores, and the empty-array pre-season edge case. It also clarifies authentication expectations (no key required, cookie unlocks more), which is 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is organized in clear blocks (purpose, returns, example, auth) and every sentence adds information. The JSON snippet is long but serves to document the output, which is justified given no output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter read-only tool, the description covers the core output structure, explain semantics, edge case, and auth context. It lacks explicit sibling differentiation, but otherwise provides sufficient context for invocation and interpretation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (gameweek: integer 1-38 required), so the schema carries the semantic weight. The description's example `{"gameweek": 1}` confirms usage but adds no extra parameter behavior beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description opens with a clear verb+object: 'Live per-player scoring for a gameweek' with the key qualifier 'as they are being earned.' This distinguishes it from sibling FPL tools like fpl_gameweeks or fpl_player_detail, which focus on schedules or static player data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it is for live scoring, with an example call and a note that empty results pre-season are normal. It does not explicitly name alternatives or state when not to use it, but the 'live' framing and empty-result semantics give enough guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• isportsapi_football_odds_asianA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the bar is lower. The description adds critical context: the payload uses positional arrays, the shape is unverified and approximate, and authentication requires the ISPORTS_API_KEY. This exceeds what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a lead sentence, a returns section, cautionary notes, and auth. Though a bit long, every sentence earns its place by adding essential warnings about the payload shape and verification status.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description takes responsibility for explaining the return format, including the positional array warning. It also covers authentication and the unverified nature of the vendor docs. Still, it lacks a concrete example of the positional arrays and doesn't elaborate on the meaning of each index.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers both parameters with clear descriptions (matchId: 'One match', companyId: 'Odds company id'), so the schema does the heavy lifting. The description does not add parameter details beyond what is already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides Asian-handicap odds across companies and explicitly positions it as the differentiator for this provider. This distinguishes it from sibling tools like isportsapi_football_schedule and apisports_football_odds.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'the reason to use this provider' strongly implies this is the default choice for Asian-handicap odds, but it does not explicitly state when to use it versus alternatives like apisports_football_odds. There is no when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• jolpicaf1_sprintA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the tool is known to be a safe, idempotent read. The description adds valuable context beyond annotations: the response shape, the specific empty-array behavior for non-sprint weekends, and the fact that no authentication is needed. This goes beyond what annotations alone convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and information-dense, including the return shape, an edge-case warning, an example, and auth status in a few sentences. It is well-structured and each sentence earns its place, though the inline JSON return shape makes it slightly dense for quick skimming.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 it does so explicitly with the MRData structure and field list. It also covers the empty-Races case, which is critical for correct interpretation. It doesn't detail nested Driver/Constructor fields, but the top-level shape is sufficient for an agent to understand the result. Given the tool's moderate complexity, this is complete enough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter (season, round, format) is already documented in the input schema. The description's only addition is a concrete example with sample values, which reinforces usage but doesn't add deeper semantic meaning beyond 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this tool returns 'Sprint race results' for F1 weekends that have a sprint, with a specific scope ('2021 onward'). The verb+resource combination ('Sprint race results') is precise and distinguishes it from sibling tools like jolpicaf1_results or jolpicaf1_qualifying by focusing exclusively on sprint races.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use the tool: for sprint results on weekends that have one. It also explicitly explains the edge case where Races is EMPTY for no-sprint weekends, which guides an agent on interpreting results. However, it does not explicitly mention alternatives or state 'use this instead of jolpicaf1_results', so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• laliga_subscriptionsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only and idempotent behavior, so the description adds extra context: authentication requirements (works without a key, optional key unlocks more) and the exact return structure. This goes beyond the annotations and helps the agent understand side effects and access needs.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first defines the concept and pagination, the second lists the return fields and auth note. Every sentence carries useful information, with no redundancy or padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple one-parameter tool, the description is fully sufficient: it explains the pagination, the return shape in detail, and authentication. The absence of an output schema is compensated by listing the exact fields. No critical information is missing for selecting and invoking this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the only parameter 'offset' with a clear description ('Pagination offset (20 per page).'). The description adds minimal extra meaning beyond confirming the pagination size, so it neither improves nor detracts from the schema's coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly defines the tool as a paginated list of season instances, clarifying that a 'subscription' equals one competition's season. It distinguishes itself from related 'laliga_competitions' and 'laliga_subscription' by specifying the list-oriented, paginated nature and the fields returned.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use for retrieving multiple season instances via pagination, but it does not explicitly state when to use this over alternatives like laliga_subscription (singular) or laliga_competitions. No exclusions or alternative guidance is provided, leaving the decision to the agent based on the plural/paginated framing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_allstar_final_voteA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already disclose read-only, idempotent, and open-world hints. The description adds valuable behavioral context by specifying the exact return structure ({league, candidates:[...]}) and stating that no authentication is needed, which goes beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: the first sentence states the purpose, the second provides the return format, and the third covers authentication. Every sentence carries unique information with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two well-defined parameters and no output schema, the description is complete. It provides the purpose, the exact return shape, and the auth requirement, covering all essential context an agent needs to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully covers both parameters with clear descriptions: 'Season year' for season and 'League id (103=AL, 104=NL)' for leagueId. The description only restates 'league + season' without adding new semantic detail, so a baseline score of 3 is appropriate given 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns All-Star 'Final Vote' candidates for a league and season, and the 'Returns:' line confirms it provides a list. This distinguishes it from sibling tools like mlb_allstar_ballot and mlb_allstar_writeins by explicitly naming 'Final Vote'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied: the description indicates the tool is for retrieving Final Vote candidates given a league and season. However, it does not explicitly mention alternatives (e.g., mlb_allstar_ballot for the general ballot) or provide when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_game_paceA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the return shape ({sports, teams, leagues}) and explicitly states no authentication is required. While annotations already declare readOnlyHint, openWorldHint, and idempotentHint, the description adds concrete output structure and auth details, contributing value beyond the structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: one sentence for purpose, one for return format, and one for auth. Every sentence contributes meaningful information without redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (3 params, no output schema), and the description provides a sufficient return structure, making output predictable. Combined with annotations for read-only/idempotent behavior, the description is complete enough for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for all three parameters (season, sportId, teamIds). The description's mention of 'optionally by team' aligns with the teamIds parameter but adds no additional syntax or behavioral detail beyond the schema, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns game-pace/tempo metrics (pitches per game, time of game) for a season, optionally filtered by team. This is specific and distinguishes it from sibling tools like mlb_schedule or mlb_standings by naming the exact metric domain.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when season-level pace metrics are needed, but it provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. It gives clear context (season, optional team filter) but does not name alternative tools or state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_scheduleA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral context by specifying the return shape and stating 'Auth: none needed', which goes beyond the annotations. No contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded. The first line states the core purpose, followed by a precise return-type block and the auth note. Every sentence serves a purpose with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description adequately documents the return structure. The parameter schema covers individual parameters, and the description adds the high-level usage (date vs. range, team filter). It is sufficiently complete for a read-only schedule tool, though it could mention the relationship between startDate and endDate more explicitly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds semantic value by tying date, startDate, and endDate together as range options and clarifying the optional team filter. This grouping helps an agent understand parameter combinations without reading each schema entry.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns a game schedule, with options for a single date, a date range, and an optional team filter. It is a specific verb+resource ('Game schedule') but does not explicitly distinguish from sibling tools like mlb_schedule_postseason or mlb_schedule_tied.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: by single date or startDate/endDate range, optionally for one team. It does not give explicit exclusions or point to alternative tools for postseason schedules, but the usage context is clear enough for an agent to decide when to invoke it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_seasonsA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds meaningful behavioral context beyond these: the exact return shape with field names, the fact that no auth is needed, and the sportId requirement. This is valuable transparency for an agent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-line purpose, a clear return shape, and an auth note. It is front-loaded and every sentence adds information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only catalogue tool, the description covers the key aspects: return fields, required sportId, and auth. It does not explicitly state that omitting 'season' returns all seasons, but the plural 'seasons' and return shape imply this. Minor gap, but otherwise complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters already described ('Filter to one season year' and 'Sport id (1 = MLB)'). The description adds little beyond 'Pass sportId=1', which is already in the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states 'Season catalogue with key dates', which clearly identifies the resource and the type of data returned. It is not fully differentiated from sibling tools like mlb_seasons_all or mlb_season, but the plural form and mention of 'catalogue' imply a list of seasons.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit instruction to 'Pass sportId=1', which is a key usage requirement. It provides clear context for when this tool is appropriate (retrieving season dates), but does not mention alternatives or exclusions, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_teamA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds explicit auth requirements ('Auth: none needed') and the return data structure, which is useful behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise (three short segments), front-loads the core purpose, and includes both return format and auth in a compact, scannable structure. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The combination of a simple tool, full schema coverage, and the description's inclusion of return format and auth makes the description fully sufficient. There is no output schema, but the description provides the needed return details, so completeness is high.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 three parameters. The description adds little beyond confirming the teamId is the key lookup, which gives it baseline credit but no extra semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses a specific verb pattern ('Single team detail by id') and clearly identifies the resource (team) and scope (by id), distinguishing it from plural or roster-focused sibling tools. It lists the attributes returned, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you have a team id but does not explicitly state when to use this tool versus alternatives like mlb_teams or mlb_team_roster. No alternative tools are mentioned, so guidance is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_team_rosterA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, open-world, and idempotent behavior. The description adds value beyond that by disclosing the exact return structure and explicitly stating no authentication is needed, which is useful context for an agent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized, with a clear opening statement, a separate Returns block, and an Auth note. Every sentence contributes useful information with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Since there is no output schema, the description compensates by providing the return format. Combined with the full input schema and read-only annotations, this gives an agent enough information to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the description doesn't need to restate parameter meanings. It does mention rosterType values but omits some options listed in the schema (fullRoster, gameday) and uses slightly different naming ('full-season' vs 'fullSeason'), adding no real semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly identifies the tool as returning a team's roster with players, positions, and jersey numbers. It also distinguishes between roster types (active, 40-man, full-season, depth chart), which separates it from sibling tools like team coaches or personnel.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when you need roster data and explains rosterType options, but it does not explicitly state when to use this tool over alternatives (e.g., mlb_team, mlb_team_coaches). No exclusions or 'use instead' guidance is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nba_boxscoreA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent. The description adds useful non-obvious details: the data comes from the CDN, the response shape (game/homeTeam/awayTeam/players), and that no auth is needed. There is no contradiction with 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: purpose, return shape, example, and auth. Every sentence earns its place, and the example is immediately useful for invocation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple single-parameter tool with no output schema. The description provides the return structure, an example, auth requirements, and the upstream source for gameId—enough for an agent to select and invoke correctly without further documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers gameId 100% with type, format, example, source, and URL-path note. The description only restates the source and adds an example, providing no new parameter meaning beyond the schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (box score for one NBA game) and scope (per-player and per-team stat lines, by period), distinguishing it from scoreboard/schedule/play-by-play siblings. It lacks an explicit verb like 'retrieves' or 'gets,' but 'Live/final box score for one game' is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states that gameId comes from nba_scoreboard_today or nba_schedule, providing a clear upstream dependency and retrieval context. It does not explicitly mention alternative tools or when not to use it, but the 'box score' scope and live/final framing give sufficient situational guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nba_daily_lineupsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by identifying the data source (stats.nba.com JS feed), noting the return shape with an example, and warning that the feed shape varies. It also explicitly states 'Auth: none needed.' This goes beyond what annotations provide, though it does not cover rate limits or deeper quirks.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the main purpose, followed by data format, return shape, example, and auth. Each sentence contributes useful information. Minor redundancy exists between the date format in the first paragraph and the example, but overall it is well-structured and economical.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with one parameter and no output schema, the description is adequately complete. It covers the data source, the query parameter, the return shape (with a caveat that it varies), an example, and authentication requirements. It could be slightly clearer about the difference between 'projected' and 'confirmed' lineups, but this is not a major gap given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 the 'date' parameter format and requirement. The description repeats the format (YYYYMMDD) and gives an example, but adds no new semantic meaning beyond what the schema provides. A baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose with a specific verb and resource: 'Projected/confirmed starting lineups for a date's games.' It distinguishes this from sibling NBA tools like nba_scoreboard_today or nba_boxscore by focusing specifically on lineups.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: for a given date's starting lineups. However, it does not explicitly mention alternative tools or exclusion criteria, so it does not earn a 5, but the usage scenario is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_playersA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and side-effect expectations. The description adds meaningful context: approximate result count, embedded objects (team, season), and the return shape (type, count, data). It also explicitly states "Auth: none needed," which is useful. No contradictions 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured into three clear sections: overview, return format, and example. It conveys all necessary information without excessive verbosity. The example is compact and practical, and the auth note is a helpful final touch. It loses one point for slight redundancy with the schema's parameter description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description compensates by explicitly listing the response structure and embedded fields. It provides a realistic example and explains the relationship between player IDs and other NBL tools. For a simple list tool with one parameter, this is complete enough for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter 'year' is already fully documented in the schema with explanation of the season start year and required status. The description adds an example (2025 = NBL26) and reiterates the parameter is part of the URL path, but these are minor additions over the schema. Since schema coverage is 100%, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this tool lists all players for a given season, specifying the resource (players) and scope (season). It distinguishes itself from sibling tools by noting the player ID feeds nbl_player_stats/nbl_player_boxscores, indicating its role in a broader workflow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: to get all players for a season, especially to obtain player IDs for subsequent stats/boxscore queries. It provides an example with a concrete year and notes the parameter is part of the URL path, but it does not explicitly state when not to use it or alternative tools for other player-related needs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_team_statsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already state readOnlyHint and idempotentHint. The description adds a concrete return shape (type, count, data array with field names) and states no auth is needed. This supplements the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is succinct and well-organized: a one-sentence purpose, a return shape snippet, an example request, and an auth note. Every sentence adds value and the structure is easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple stats tool with two well-documented parameters, the description covers the essentials: what data is returned, how to invoke it (example), and auth requirements. No external output schema, so the return snippet fills that gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with detailed descriptions for both 'year' and 'seasonType'. The description adds an example but no additional parameter semantics beyond what the schema already provides, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns team statistics for a season, listing the specific stats categories (totals and per-game averages). It is clear what the tool does, though it does not explicitly differentiate from sibling tools like nbl_player_stats or nbl_stat_leaders.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it: when you need team-level season totals/averages, with an example request for the current season. It does not explicitly exclude alternatives or state when not to use it, but the context is clear enough for an agent to decide.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ncaa_scoreboardA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly/OpenWorld/idempotent; the description adds a detailed return structure, the note about one-key object wrapping, and Auth:none needed. No contradictions. It doesn't mention rate limits or empty results, but for a read-only scoreboard the critical context is covered.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tightly organized: a one-line summary, a Returns block, a structural note, a concrete example, and Auth. Every line carries useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 100% schema coverage and readOnly/OpenWorld/idempotent annotations, the description needs mainly to explain the return payload; it does so with a detailed pseudo-schema and the one-key quirk. The example further clarifies parameter usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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's example reiterates the schema defaults (football/fbs) without adding new parameter meaning. No additional semantics needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Current scoreboard for one college sport and division', clearly identifying the tool's resource and scope. It distinguishes from siblings like espn_scoreboard by limiting to one college sport/division, but doesn't name an alternative explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It establishes clear context: use when you need current NCAA scores for a specific sport/division, with an explicit FBS football example. However, it doesn't state when-not-to-use or name alternatives, so not a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhl_club_scheduleA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context: response size (~200 KB), auth requirements ('Auth: none needed'), and a detailed return shape. It doesn't cover rate limits or data freshness but goes beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a one-sentence summary, a compact return format snippet, an example, and an auth note. All content is relevant, though the return snippet is somewhat lengthy, it earns its place by showing the response shape.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity and strong annotations, the description covers the key aspects: purpose, response structure, size, example, and auth. No output schema exists, but the return snippet compensates well. It doesn't need further detail for a read-only data retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for both parameters with 100% coverage. The description's example adds concrete values but no additional semantic meaning beyond the schema, so it meets the baseline without compensating for any gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'One club's entire season schedule with results — the team game log,' which clearly defines a specific resource and scope. It distinguishes itself from broader sibling tools like nhl_schedule by focusing on a single club's full season.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context that this is for a single club's full season and includes a concrete example (TOR, 20242025). However, it does not explicitly name alternative tools or state when not to use it, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhl_playerA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds 'Auth: none needed' and details the exact return object, including nested structures like draftDetails and careerTotals, which provide concrete behavioral expectations for a read-only endpoint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a one-line purpose, a return-format block, an example, and an auth note. It's slightly verbose due to the full return object listing, but each section is distinct and serves a purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given a single parameter and no output schema, the description compensates by enumerating the return fields and providing an example. It covers purpose, parameter origin, example usage, and auth, making it complete for a simple read-only player lookup.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already explains playerId with a 100% coverage description, including its source and URL path role. The description adds an example value (8478402 for McDavid) but no new semantic information, so it stays at the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'One player's landing page: bio, draft details, current season splits, career totals and awards,' which clearly identifies the resource (a single player) and the content scope. It differentiates from sibling tools like nhl_roster by emphasizing 'one player' and the landing page aggregation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states the playerId comes 'from nhl_roster or a box score,' providing clear context for when to call this tool (after obtaining a player ID). However, it doesn't explicitly name alternatives or state when not to use it, so it stops short of full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhl_scheduleA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, open-world, and idempotent behavior. The description adds useful context: the return value structure, grouped-by-day organization, and 'Auth: none needed.' This goes beyond what annotations provide without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear first sentence, a compact return type definition, and a practical example. It is slightly lengthy due to the return block, but every sentence adds value, especially since there is no output schema to rely on.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with a single optional parameter, the description covers the main use case, return format, and authentication requirements. It lacks explicit guidance on divergences from sibling tools (e.g., nhl_club_schedule) but otherwise provides sufficient context for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully documents the 'date' parameter with format and meaning, achieving 100% schema coverage. The description's example ('date: now') is redundant, adding no new semantic information beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns the league schedule for a week, grouped by day, with a specific resource (league schedule) and verb (retrieve). This distinguishes it from sibling tools like nhl_club_schedule, which focuses on a single club's schedule.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it handles the current week or a given date's week, with an example using 'now'. It does not explicitly mention when not to use it or name alternatives, but the scope is unambiguous and the example clarifies typical usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opendota_matchA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint. The description adds a useful LARGE (~250 KB) warning and details the return structure including interpreting player_slot, providing additional behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded, with the size warning placed early, followed by a compact return object, an example, and auth info. No filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even without an output schema, the description includes a representative return object, explains player_slot semantics, flags response size, and notes auth requirements, making it a complete and practical specification for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers match_id 100% with a description that mentions it's required and a URL path parameter. The description's example value matches the schema; no additional semantics are added beyond the example.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Full detail for one match' and enumerates all included data (hero, items, KDA, gold/XP curves, objectives). This distinguishes it from list-type OpenDota siblings like opendota_pro_matches and opendota_public_matches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It doesn't explicitly state when to use it over alternatives, but the name and example imply it's for fetching a specific match after obtaining an ID. The schema notes the match_id comes from opendota_pro_matches, but that's not in the description itself.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_locationA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, open-world, and idempotent hints. The description adds meaningful behavioral context: real-time sampling rate (~3.7 Hz), high-volume warning, return shape as a top-level large array, and no auth needed. This enriches beyond the annotations without any contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: first sentence states the data and frequency, second warns about high volume and required parameters, third gives the return shape, fourth states auth. Every sentence earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple location tool with no output schema, the description covers data, frequency, usage constraints, return shape, and auth. It lacks explicit differentiation from similar openf1 tools (e.g., openf1_position) or coordinate system details, but overall it provides sufficient guidance for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all three parameters. The description reiterates the necessity of session_key and driver_number but does not add new semantic details beyond the schema, such as exact formats for 'latest' or how a date window would be specified.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning car track position (x,y,z) at ~3.7 Hz, specifying the resource and data fields. However, it does not explicitly differentiate from sibling tools like openf1_position or openf1_car_data, relying on the coordinate details rather than naming alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly warns about HIGH VOLUME and instructs to always pass session_key and driver_number, and ideally a date window, which is clear usage context. It does not mention explicit alternatives or when-not-to-use scenarios, so it stops short of a top score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_weatherA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context beyond this: update frequency (~once a minute), the exact return shape (array of objects with listed fields), and explicit 'Auth: none needed'. This goes beyond what annotations provide and informs the agent about freshness and response structure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly efficient: two brief sentences cover the purpose, update frequency, data fields, return format, and auth requirements. No filler or redundant restatement of the name or schema. Front-loaded with the core action and data types.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two optional params and no output schema, the description is complete. It tells the agent what data is returned, how fresh it is, and that no auth is needed. The parameters are well-documented in the schema, so the description doesn't need to repeat them. This is fully sufficient for an agent to decide to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — both meeting_key and session_key have descriptions ('Meeting key, or latest') and defaults. The description adds no additional parameter semantics beyond what the schema already defines, so the baseline score of 3 applies rather than a higher one.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb+resource: "Track weather" and enumerates the exact measurements (air/track temperature, humidity, pressure, wind, rainfall). This distinguishes it from sibling openf1_* tools which focus on other data types like laps or positions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied but not explicitly stated. The description says "Track weather" and lists fields, but does not explicitly say 'Use this when you need session weather conditions' or contrast it with alternatives (though no direct sibling exists). It does mention no auth needed as a prerequisite, which is useful but not a full when-to-use/when-not-to-use guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_sport_matchupsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds return structure, an auth note, and an example, which is useful extra context. It does not mention pagination or sorting, but the annotation coverage lowers the burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-line purpose, a return array, an example, and an auth note. Every sentence adds necessary information without redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with a single parameter, the description provides sufficient information: return shape, example invocation, and auth requirements. The missing definition of 'highlighted' is a minor gap, but the open-world hint and simple scope make it adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description fully covers sportId ('Sport id, from pinnacle_sports. Required — part of the URL path.'), so the description adds no additional semantics beyond the schema. The example (sportId: 3) is a usage illustration but not new parameter meaning, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states 'Highlighted matchups for one sport' – a specific verb ('returns') with a clear resource ('matchups') and scope ('one sport'). It distinguishes from siblings like pinnacle_sport_matchups_all and pinnacle_league_matchups via the word 'highlighted' and 'one sport'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies it is for featured/highlighted matchups as opposed to all or live variants, but it does not explicitly name alternatives or exclusions. The example shows how to call with sportId but provides no clear when-to-use vs. when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_sports_liveA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that authentication is not needed and provides the exact return array format, giving useful behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise: one sentence for the core purpose, a return type specification, and an authentication note. It is front-loaded and contains no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list tool, the description is complete. It specifies the top-level array structure, fields, and auth requirements. The open-world nature is already covered by annotations, and no output schema exists, so the explicit return format is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema is empty (zero parameters), so the description does not need to explain parameter semantics. According to the rubric, a baseline of 4 applies for zero-parameter tools, and the description adds no unnecessary parameter information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's purpose: to return sports that currently have live (in-play) matchups. It specifies the return structure with fields like id, name, matchupCount, and primaryMarketType, which distinguishes it from sibling tools like pinnacle_sport_matchups_live that return matchups for a given sport.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no explicit guidance on when to use this tool versus alternatives like pinnacle_sport_matchups_live or pinnacle_league_matchups_live. The description simply states what it returns, leaving the agent to infer usage context from the tool name and sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_statusA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only and idempotent behavior. The description adds that no authentication is needed and specifies the response shape, which is useful contextual information 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, with a clear statement of purpose, a return-format line, and an auth note. Every sentence earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter status check, the description fully covers the purpose, return format, and authentication requirements. It is sufficient without an output schema, and the sibling context does not demand additional disambiguation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema coverage is 100%, so no parameter details are needed. The description appropriately focuses on the output, giving it the baseline 4 for a no-parameter tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool reports API system status with online/offline and per-service health, and specifies the return structure. This distinguishes it from other status tools in the sibling list by detailing per-service health.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool versus alternatives like kalshi_exchange_status or apisports_status. The implied usage is to check Pinnacle API status, but there are no exclusions or alternative recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_competitionsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds value by stating pagination behavior, the return shape ({pagination, data:[{id, code, name}]}), and that no authentication is needed, which goes beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and efficient, covering purpose, pagination, return format, and auth in three short sentences. Every sentence carries useful information with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with no output schema, the description provides essential details: what resource is returned, pagination, return structure, and auth. It also includes a specific example (Premier League = id 8). This is sufficient for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 mentions pagination but does not add detail about limit or next_cursor beyond what the schema already provides (page size and opaque cursor). No additional semantics are given for the parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: listing all competitions on the platform. It gives the specific Premier League ID as an example, making the resource unambiguous. This distinguishes it from sibling tools like pl_competition (singular) which likely fetches a single competition.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving all competitions but does not explicitly state when to use this tool over alternatives like laliga_competitions or afl_competitions_list. It mentions pagination and the Premier League ID, but no exclusions or explicit context for choosing this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_match_eventsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context: the return structure and 'Auth: none needed'. It does not describe error handling or edge cases, but for a simple read-only operation with good annotations, this is sufficient extra behavioral detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and well-structured: first line describes the content, second line gives return format, third line states auth. No wasted words; every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one parameter, clear annotations, and no output schema, the description is complete. It provides the exact return shape, making the output predictable. The lack of output schema is mitigated by the explicit return type description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the single parameter 'id' is already well-described as 'Match id. Required — part of the URL path.' The description adds no further parameter semantics, but the schema fully documents it, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the resource (match events) and specifies the exact content (goals, cards, subs) and split by home/away team. It includes the return structure, distinguishing it from sibling tools like pl_match_lineups and pl_match_stats. Though lacking an explicit verb, 'Match events' unambiguously implies retrieval.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for fetching match events for a given match id, but provides no explicit when-to-use guidance or comparisons to alternatives. It doesn't mention exclusions or when not to use this tool, leaving the agent to infer from context among many pl_* siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_team_leaderboardA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint, so the tool is known to be safe and idempotent. The description adds valuable context by stating 'Auth: none needed', clarifying that 'season is a query param here, not a path segment', and showing the return shape. No contradictions 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a concise opening, a note, return shape, an example, and authentication info. It is somewhat verbose but every section adds value, and the information is front-loaded. The example and return shape are useful, though the row description is redundant with the return format.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity and the absence of an output schema, the description kindly provides the return structure and a concrete example. It also covers authentication and the API quirk about the season parameter. This is sufficiently complete for an agent to invoke the tool correctly, though pagination details are left to the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, meaning each parameter is already well-documented (e.g., cid is 'Competition id (8)', sort is 'Sort metric:dir', limit default is 20). The description does not significantly add to this beyond the concrete example, which reinforces but does not expand the semantics. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Team stat leaderboard — sort by any Opta team metric', which is a specific verb+resource+scope. It distinguishes from sibling tools like pl_standings and pl_player_leaderboard by focusing on team metrics and sorting, and the example with '2025/26 teams by tackles won' further clarifies the exact use case.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool: to retrieve a sortable team stat leaderboard based on Opta metrics. It provides a concrete example and notes the season as a query parameter, which gives clear context. However, it does not explicitly mention alternative tools or when not to use it, though the purpose is distinctive enough among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_teams_by_idA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, and the description aligns with these by calling it a 'lookup.' It adds useful behavior beyond annotations by specifying the exact return shape ([{id, name, shortName, abbr, stadium}]) and stating 'Auth: none needed.'

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded: a one-line purpose, a return structure line, and an auth line. There is no redundant or filler text; every sentence provides essential information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple one-parameter batch lookup with high schema coverage and informative annotations. The description covers purpose, return format, and auth requirements, so it is sufficiently complete for an agent to invoke correctly without an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the id parameter as an array of team ids with an example ([14, 43]), yielding 100% schema coverage. The description itself adds no extra parameter details, but given the high schema coverage, the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Batch team lookup by a list of ids,' which clearly identifies a batch read operation on teams. It distinguishes itself from sibling single-team tools like pl_team by explicitly noting the batch/list nature, and the return field list adds concreteness.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The word 'Batch' implies the tool is for looking up multiple teams at once, but there is no explicit mention of when not to use it or alternatives (e.g., pl_team for a single team). The usage guidance is only implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_racing_racesA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare safe read/idempotent behavior. The description adds value by specifying 'Auth: none needed' and providing the exact return structure, which helps set expectations. It does not mention error handling or ordering, but the annotations lower the burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise and well-structured: a single purpose sentence, a returns block, and an auth note. Every sentence contributes useful information with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool with one parameter and good annotations, the description covers the core aspects: purpose, return shape, and auth. However, the missing parameter format clarification and lack of explicit differentiation from the single-race sibling tool leave minor gaps in completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool description does not clarify the 'raceIds' parameter format. The schema description says 'Comma-separated race ids' while the type is 'array', creating ambiguity. With 100% schema coverage, the baseline is 3, but the description fails to resolve the contradiction or add any meaningful parameter guidance, so it actually underperforms.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns racecards for multiple races in a single call, using 'batch by race ids'. This distinguishes it from the singular 'pointsbet_racing_race' sibling and conveys the specific resource and batching behavior.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for fetching multiple racecards at once, which is clear context. However, it does not explicitly name alternative tools (e.g., pointsbet_racing_race for a single race) or state when not to use this tool, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_sports_listA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context beyond this: the date token does not affect the response ('returns the current catalogue regardless'), auth is not needed, and the return shape is given. This goes beyond the annotations, though it doesn't discuss pagination or size.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: a one-line purpose, a return shape line, an example, and an auth note. Each sentence carries useful information without waste, and the structure front-loads the main purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter, read-only, list-type tool with strong annotations, the description is complete. It covers the return structure, an example invocation, and the auth requirement. The absence of an output schema is compensated by the inline return format.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and the input schema already explains the date parameter thoroughly: format, that any valid token works, and that it's part of the URL path. The tool description only repeats an example and adds no new parameter semantics, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns the 'Full catalogue of sports and their competitions (every code, featured flags)' – a specific resource with explicit scope. This distinguishes it from sibling tools like pointsbet_sport_competitions (specific sport) and pointsbet_sports_inplay (in-play only).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage – you call this when you need the complete sports/competitions catalogue – but it never explicitly says when to use this vs alternatives or provides exclusions. The scope is clear via 'full' and 'every code', but no alternative tools are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sleeper_league_rostersA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the description need not repeat those. It adds value by stating 'Auth: none needed' and including the exact return structure and a join hint, which are beyond what annotations provide. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-line summary, a return format, an example, and auth note. No superfluous words. Information is front-loaded, and the example is concrete.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (single parameter, no output schema), the description is complete: it outlines the return fields, provides an example call, and mentions authentication. It also gives a useful join hint for interpreting owner_id. No critical gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, league_id, is fully described in the schema as 'League id. Required — part of the URL path.' The description adds an example value but does not significantly enhance the semantic meaning beyond the schema. With 100% schema coverage, baseline is 3, and the example is a minor bonus.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns every roster in a league, including player IDs, starters, and season record. It distinguishes from sibling tools like sleeper_league (league info) and sleeper_league_users (user info) by specifying its focus on rosters. The verb 'get' is implied but the resource and scope are unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating it returns rosters for a league, but it does not explicitly mention when to use this tool over siblings like sleeper_matchups or sleeper_league_users. No exclusionary or alternative guidance is provided, but the purpose is clear enough for an agent to infer appropriate invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_event_commentaryA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, idempotent, and open-world behavior. The description adds the return format structure and states 'Auth: none needed,' which goes beyond annotations. It also notes 'Live' to indicate real-time data, providing useful context without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two sentences cover purpose, return format, and auth. It is front-loaded with the key action and includes only essential details. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema, the description provides the return structure explicitly ('{events:[{eventId, score, commentary:[{time, text}]}]}'), the auth requirement, and live nature. With strong annotations, this is sufficient for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% because the only parameter eventIds has a description ('Comma-separated sport event ids.'). The description adds that the tool supports 'one or more' events, but this is minimal extra value beyond the schema. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides 'Live score + text commentary for one or more sport events,' using a specific verb (live score/commentary) and resource (sport events). It distinguishes from sibling tools like sportsbet_event_results or sportsbet_event_status by focusing on commentary.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case (when you need live score and text commentary) but does not explicitly mention alternatives or when not to use it. With many sportsbet sibling tools, some explicit differentiation would help, but the purpose is clear enough for basic selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_event_marketsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds useful behavioral context by explicitly stating 'Auth: none needed' and specifying the return structure with 'live prices,' which informs the agent about data freshness and authentication requirements 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, front-loaded with the core purpose, and includes a compact return structure example. Every sentence serves a purpose: scoping, output format, and authentication. No unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with one parameter and a well-defined return schema in the description, this is complete. The agent knows exactly what data to expect and in what shape, satisfying the information needs for this low-complexity tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 eventId as required and part of the URL path. The description does not add further parameter meaning beyond what the schema provides, maintaining the baseline score for complete schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: retrieving all markets, selections, and live prices for a single sport event. The verb 'returns' followed by specific resource components (markets, selections, prices) makes the purpose unambiguous and distinguishes it from event lists or results tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for a single sport event but does not explicitly state when to use this tool over alternatives like betfair_markets_by_event or tab_match_markets. No exclusions or alternative references are provided, relying on the reader to infer the intended context from the phrase 'one sport event.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_racing_allracingA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is known. The description adds the return structure and an example, but does not disclose deep behavioral details like date boundary handling, ordering, or potential errors. It provides moderate added 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: purpose sentence, return shape, example, and auth note. Every line serves a purpose, with no fluff or repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description provides the return format and a usage example, making the tool's behavior clear for a simple 1-parameter operation. It covers the essential aspects an agent needs to invoke and interpret results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes eventDate with format and required status (100% coverage). The description only adds an example with a placeholder, which does not significantly extend the semantic meaning beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action and resource: 'All race meetings (every code) for one date, grouped by meeting.' This clearly distinguishes it from sibling tools like meeting-specific or racecard tools by emphasizing the all-codes, single-date scope and the grouping behavior.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context for use ('All racing for a given day') and an example, but does not explicitly name alternatives or state when not to use it. It gives enough context for an agent to infer its purpose, but lacks direct exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_racing_top_jockeysA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that no authentication is needed and provides the exact return structure, which adds useful behavioral context beyond the read-only annotation. It also scopes the data to 'today,' giving the agent a clear expectation of the response. However, it doesn't mention potential data latency or whether the list is sorted, but given the annotations, this is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short, information-dense sentences, with the return type front-loaded. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, zero-parameter, read-only tool, the description is complete: it states the data (top jockeys and rides), the time scope (today), the return format, and auth requirement. No output schema exists, so the inline return type fills that gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Since the tool takes zero parameters, the schema already fully describes the input, and the description adds nothing needed on parameter usage. The baseline for zero-parameter tools is 4, which is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as providing leading jockeys and their rides for today, with a return shape that defines the scope. It uses a specific resource ('top jockeys') and action ('rides today'), distinguishing it from other racing tools that focus on races or bets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no guidance on when to select this tool over alternatives, nor does it mention exclusions or related tools. A user would know what it does but not when it's the best choice among the many racing endpoints.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsdata_feedbackA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are all false (readOnlyHint=false, openWorldHint=false, idempotentHint=false), providing almost no guidance, so the description must carry the burden. It does so well by disclosing that feedback is recorded locally, only transmitted if SPORTSDATA_TELEMETRY=1 plus a configured endpoint, and that `note` is sent verbatim – important privacy context. It doesn't mention the return value or any server-side effects beyond recording, but the core behavior is transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three well-structured sentences: the first states the purpose, the second gives usage context, the third covers privacy. It's front-loaded and every sentence earns its place. Slightly verbose in the middle clause, but still efficient and clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple feedback tool, the description covers the trigger conditions, the specific failure mode to report, and the privacy/telemetry behavior. An output schema is present (unseen), so return values need not be described. A minor gap is that it doesn't state what happens after recording (e.g., whether feedback is anonymous), but this is not essential for invoking the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%; each parameter (helpful, tool, note) has a detailed description in the schema itself. The tool description reiterates the privacy caution about `note` being sent verbatim but adds no new meaning beyond the schema. The baseline of 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Report whether an answer from this server was useful' – a specific verb and resource. It clearly distinguishes itself from the hundreds of sibling data-retrieval tools by being the only feedback/reporting tool, and it even specifies the exact failure mode (response shape mismatch) that maintainers most need to hear about.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states 'Call this when a tool gave a wrong, empty or misleading answer' and gives a concrete example of when to use it. It doesn't explicitly list when-not-to-use or suggest alternative tools, but the use case is so distinct from the siblings that this is largely unnecessary.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• squiggle_teamsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral details beyond annotations, such as the return shape, the sentinel value 'retirement 9999 means still active', and the lack of required auth. This enriches the agent's understanding of what the tool actually returns.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the core purpose in the first sentence. Each subsequent piece (return shape, sentinel, example, auth) adds meaningful information without redundancy. It is slightly longer than strictly necessary, but all content earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple look-up tool with no output schema, the description is quite complete: it covers purpose, return format, special sentinel value, example usage, and auth requirements. The only minor gap is that it does not elaborate on the year parameter, but the schema handles that. Overall, the tool is well-specified for its complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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. Both parameters (q and year) are fully described in the schema: q is 'Leave as-is' and year restricts to teams active in a season. The description reinforces q usage through an example but does not add additional semantics beyond the schema, so it meets, but does not exceed, the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that this tool returns AFL clubs with Squiggle's team IDs, and emphasizes that this ID is the key every other Squiggle tool uses. This distinguishes it from many sibling tools that also list AFL teams (e.g., afl_teams_list, afl_clubs_list) by highlighting the Squiggle-specific ID mapping.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'the id every other Squiggle tool keys off', which signals when to use this tool: when you need Squiggle team IDs to use in other Squiggle tools. It also provides an example call and notes that auth is not needed. However, it does not explicitly name alternative tools or state when not to use it, so it misses the full 'when-not' guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• squiggle_tipsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavior beyond the annotations by explaining that 'correct is null until played' and that 'confidence is a %, bits is the model's information score'. It also flags that a whole season is ~100 KB via the round parameter, which sets an expectation for payload size. Annotations already declare read-only/idempotent, and the description doesn't contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loads purpose, followed by a structured return block, example, and auth note. The 'Also answers this: apisports_football_predictions' feels slightly cryptic but is not fluff; overall it's efficient and well-organized.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 listing return fields with explanations and giving a concrete example. It covers auth, example, and key behaviors, though it doesn't mention pagination or error handling. For a read-only tool with 6 clearly-described parameters, this is adequate and above minimum.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and every parameter has a description, so the baseline is 3. The description adds an example call but doesn't elaborate on individual parameters beyond what the schema already provides; it focuses on the return shape instead.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: it explains exactly what the tool returns ('What each model tipped for a game') and lists key fields (winner, margin, confidence, correctness). This clearly distinguishes it from sibling squiggle tools like squiggle_games or squiggle_sources, which handle games and model metadata respectively.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides a concrete example for a common use case ('Every model's tips for round 1, 2026') and notes that no auth is needed. It also hints at an alternative by stating 'Also answers this: apisports_football_predictions', which helps route similar questions. However, it doesn't explicitly say when to prefer this over squiggle_games or other prediction-related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• supercoach_real_fixtureA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnly/openWorld/idempotent annotations, the description adds useful behavioral context: the return shape (array of fixture objects), approximate season size (AFL ~207 rows), pagination behavior, and the fact that no auth is needed. This goes beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a purpose statement, usage notes, return field list, example, and auth note. It's a bit longer than minimal, but every section adds value for an agent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description provides a detailed field list and example, covering the main behaviors. It lacks explicit statements about sorting or error cases, but overall it gives enough context for selecting and invoking the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds minor value by noting the AFL season size for pagination and showing an example, but parameter meanings are already fully covered in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it returns fixtures for a SuperCoach game+season, including kickoff, teams, venue, scores, live status, and head-to-head odds. The example with sport/year/round and the detailed field list distinguish it from sibling fixture tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explains the round parameter (pass for one round, omit for full season), pagination, and provides an example. It doesn't name alternative tools or give when-not-to-use, but the context makes the intended use clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_matchA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the description doesn't need to repeat safety. It adds useful context: the return structure (id, name, startTime, markets, sameGame, contestants, inPlay, stats) and the auth behavior (works without a key, TAB_CLIENT_ID/SECRET unlocks more). This goes beyond annotations by explaining what data is returned and the auth requirement.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-line summary, a return structure block, an example, and an auth note. Every section adds value. The example is particularly useful. Slightly verbose with the JSON return structure, but it's informative and not excessive.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (full match book with markets, SGM, contestants, live state, stats), the description covers the key aspects: what it returns, how to call it, and auth requirements. It doesn't explain pagination or rate limits, but those aren't mentioned in annotations either. The output schema is absent, so the return structure in the description is essential and well-provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all parameters. The description adds an example with actual values (AFL Football, AFL, Adelaide v Geelong) which helps the agent understand the format. However, it doesn't add much beyond the schema for the jurisdiction parameter (which has a default). Baseline 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Full match book: all markets + bet options, Same Game Multi, contestants, live state and stats.' It specifies the resource (match book) and the scope (all markets, bet options, SGM, contestants, live state, stats). It distinguishes from siblings like tab_match_markets (which likely only returns markets) and tab_multi_builder (which builds multis).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete example of how to use the tool with parameters (sport, competition, match) and notes that it works without a key, with optional auth for more data. It doesn't explicitly state when to use this vs alternatives, but the example and the 'full match book' scope imply it's the comprehensive match data tool. Sibling tools like tab_match_markets are more specific, so the usage context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_match_marketsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag read-only, idempotent, and open-world behavior. The description adds value by disclosing auth requirements (works without a key, unlocks more with credentials) and detailing the response shape. This is useful beyond the annotations, though it doesn't cover potential edge cases like 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-line summary, return type, example, and auth note. It avoids redundancy and is front-loaded with the primary purpose. Slightly verbose with the example but necessary for clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with four parameters and no output schema. The description provides the return structure, an example, and auth context. While it doesn't mention any limits or pagination, it's likely unnecessary for a lean market query. The description is sufficiently complete for its complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for all parameters, including the requirement to pass raw spaces. The description adds an example but does not enhance parameter understanding beyond what the schema already offers. Per rubric, with high coverage, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns "the markets + selections + prices for one match" and highlights it is leaner than the full match object. It includes an explicit return structure and an example, making the purpose unambiguous and distinguishing it from the likely sibling tab_match.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase "leaner than the full match object" signals when to prefer this tool over a more detailed alternative. It does not explicitly name tab_match as the alternative, but the implication is clear. The example also demonstrates expected usage, providing adequate context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wta_tournament_matchesA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: 'Auth: none needed,' the approximate result size (~302 matches), and the field structure of the return payload. This gives the agent a good sense of what the response contains without needing to invoke the tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately long but well-structured: a clear opening line, a return field list, an example, and an auth note. Every section adds useful information. It is front-loaded with the core purpose, and the example is concise. Slightly verbose due to the full return field list, but that is justified given there is no output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has only 2 parameters and no output schema, the description provides a comprehensive picture: purpose, return fields, example, and auth requirements. It covers the essential context an agent needs to decide to use the tool and interpret results. It does not address pagination or filtering, but the tool appears to return all matches at once, and the openWorldHint annotation mitigates concerns about data completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for both parameters (groupId and year) with 100% coverage. The description adds an example mapping (groupId 901, year 2025) and clarifies that groupId comes from wta_tournaments, but this is marginal value beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns all matches/results for a specific tournament edition identified by group id and year. It differentiates itself from sibling tools like wta_tournament (single tournament info) and wta_player_matches (matches for a player) by explicitly scoping to one tournament edition. The example (AO 2025) further reinforces the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage context: 'Use for draws + results.' This tells the agent when to select this tool. It does not mention when not to use it or name alternatives, but the example and the tool name itself make the context clear, which is sufficient for a clear but not fully exhaustive guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_league_settingsA
  4.1/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the read-only and idempotent annotations, the description discloses auth requirements, explicitly warns that the response shape is unverified vendor documentation, and advises inspecting the live payload before relying on field names. This is genuinely useful behavioral context that helps the agent avoid overconfidence.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well structured: directive, return shape, caveat, example, and auth each occupy a clear section. The return shape block is long but justified because there is no output schema; no sentence feels wasted.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 providing a detailed return shape, a reliability caveat, an example, and auth notes. It does not cover error cases or explicitly compare with sibling yahoo league tools, but those are non-essential for a read-only settings tool with strong annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents both parameters. The example `{"leagueKey": "449.l.12345"}` reinforces the expected format but does not add meaning beyond the schema; baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a league-settings reader by enumerating the content: roster slots, scoring weights, waiver type, trade deadline, and playoff structure. It would be stronger with an explicit verb like 'retrieve' or 'get,' and it does not directly contrast with sibling league tools, but the scope is unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The instruction 'Read this before proposing anything' is an explicit usage cue, and the paragraph about `uses_faab` adds a concrete decision-relevant context: an agent must know waiver behavior before claiming. It does not name alternative tools or provide when-not-to-use guidance, which prevents a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_content_video_getA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by specifying 'Auth: none needed' and detailing the exact return fields. This goes beyond the structured hints and provides practical invocation context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise with three short sentences, each serving a purpose: action, return shape, and auth. It is front-loaded and free of filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-id get operation with rich annotations, the description is sufficient: it names the resource, return format, and auth. It lacks error-handling notes, but these are not essential for this low-complexity tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the single 'id' parameter is already well-documented in the schema. The description adds no additional parameter semantics beyond the verb 'by id', so it does not go beyond the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get a single video content item by id') with a specific verb and resource. It distinguishes from siblings like afl_content_video_list and other content-type get tools by explicitly scoping to a single video item.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys when to use the tool (when you have an id and need a specific video item). It does not explicitly mention when not to use or name alternatives, but the context is clear given the sibling list tool and the id parameter requirement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_matches_listA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral details: 'Auth: none needed', the exact return shape (meta.pagination and matches array with key fields), and an example combining status, startDate, and competitionId. These go beyond the annotations and schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: a one-sentence function overview, a return shape, a concrete example, and an auth note. Every line earns its place with no redundancy or vague filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 10 optional parameters and no output schema, the description compensates well by documenting the return shape, providing a realistic example, and stating auth requirements. It doesn't explain pagination defaults or sort behavior, but those are adequately covered by the schema descriptions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides descriptions for all 10 parameters (100% coverage), so the description does not need to explain each parameter. The example shows a practical combination of status, startDate, and competitionId, which adds some usage context, but it does not add semantic meaning beyond what the schema already offers.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'List matches with filters' which is a specific verb+resource and clearly indicates the tool's list/filter purpose. It distinguishes itself from siblings like afl_match_get (singular match) and afl_matches_idmap (id mapping) by emphasizing filters and listing the filter dimensions (competition, season, round, team, status, date).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example 'Live + upcoming AFL matches from a date' provides concrete context for a common use case, implying when to use this tool (filtering matches by status/date). However, there is no explicit mention of alternatives or when not to use it, which keeps it just shy of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_statspro_callA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations already indicating readOnlyHint, idempotentHint, and openWorldHint, the description adds useful context: the anonymous x-media-mis-token is minted automatically, path params use provider IDs (CD_S*/CD_R*/CD_I*), and it points to a catalogue resource. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose. Every sentence provides distinct value: the API base path, token requirement, provider ID convention, catalogue pointer, and return type. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a generic dispatcher tool with high complexity, the description covers the essentials: what it calls, where to find the operation list, token requirements, and path parameter conventions. It does not describe error behavior or response schema, but the input schema and catalogue resource fill those gaps, and no output schema exists to require more detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description adds specific guidance that path params use provider ID formats (CD_S*/CD_R*/CD_I*), and references the catalogue resource for discovering valid operation names, which enriches the parameter understanding beyond the schema's own descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it calls 'any of the AFL StatsPro operations' with the specific API base path, making the verb and resource explicit. It distinguishes itself from dedicated AFL tools (like afl_competition_get) by being a generic dispatcher, and directs users to a catalogue resource for operation names.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It implies usage through 'Call any of the AFL StatsPro operations' and 'Read afl://statspro/operations for the list,' giving context on how to discover operations. However, it does not explicitly say when to use this tool instead of the many dedicated AFL sibling tools, nor does it mention exclusions or preferred alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_team_getA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context beyond those flags: 'Auth: none needed' and a concrete return shape '{teams:[...]}', which help the agent understand what to expect without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: one sentence for purpose, one for return format, one for auth. Every sentence earns its place with no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-id tool with one parameter, strong annotations, and no output schema, the description covers the essential aspects: purpose, return shape, and auth. It lacks explicit error behavior or field-level explanations, but these are not critical for basic selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the teamId parameter is already well described with an example ('e.g. 1 = Adelaide Crows') and a URL path note. The description only echoes 'by id' without adding new meaning, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches a single team by id, with a specific verb ('Get') and resource ('a single team by id'). It adds 'incl. social/home-venue metadata' to differentiate from list/mapping siblings like afl_teams_list and afl_teams_idmap.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description establishes clear context: use when you have a specific teamId and need a single team's details, including metadata. However, it does not explicitly name alternatives or exclusion cases (e.g., use afl_teams_list for multiple teams), so it stops short of full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_hockey_gamesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds valuable behavioral context: the return shape is explicitly unverified and approximate, the user must supply their own API key, and the NHL provider alternative is noted as deeper/live (implying this provider may be less detailed). This goes beyond the annotations by disclosing reliability caveats and authentication requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the primary purpose. It includes a return shape, a critical verification caveat, a concrete example, and an auth note—each sentence earns its place. It is concise without being terse, and the caveats are clearly separated. No irrelevant information is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a return shape (albeit tagged as approximate), an example, auth requirements, and a comparison with the NHL provider. This covers essential information for invoking the tool. However, it does not specify whether parameters are required (none are), how multiple parameters interact, or any pagination/limits, leaving some operational uncertainty.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all 4 parameters with brief descriptions (e.g., 'YYYY-MM-DD', 'Team id.'), achieving 100% schema coverage. The description adds an example for the `date` parameter and mentions 'by date or league', but does not resolve ambiguity about parameter combinations (e.g., can `team` and `league` be combined with `date`? Does `season` require `league`?). Thus it adds some value but does not fully compensate for potential combination confusion.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Ice-hockey games (NHL, KHL, SHL and others) by date or league' which is a specific verb (retrieve/list) + clear resource (ice-hockey games) + scope (by date or league). It also distinguishes the tool from the official NHL provider by noting it is 'deeper and live' for the NHL itself, helping differentiate among similar sports tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit alternative for NHL data ('the keyless official `nhl` provider is deeper and live'), which serves as a when-not-to-use for NHL-specific queries. It also implies usage context via 'by date or league' and provides an example. However, it does not clarify when to use the `team` or `season` parameters or how they combine with date/league, leaving some usage ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betfair_navigationA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety profile is clear. The description adds useful behavioral context: 'Auth: none needed' and a return structure example. It does not discuss rate limits or pagination, but given the read-only nature and the annotations, the description adds sufficient value beyond structured data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-line function summary, a returns block, an example, and an auth note. Every sentence adds value, and the structure is easy to scan. No unnecessary repetition of schema information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having 9 parameters and no output schema, the description provides a partial return structure, an example, and integration guidance. The schema covers parameter semantics fully. The combination gives an agent enough to invoke the tool correctly, though it lacks details on pagination or full response shape, so it is not a 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with descriptions for all 9 parameters. The description provides an example using 'nodeIds' and mentions the nodeType enum in the return shape, which indirectly helps understand parameter values. However, it does not add significant meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Navigation graph by node — traverse sport → group → event → market.' It uses a specific verb ('traverse') and resource, and provides a concrete example (Horse Racing tree). It also distinguishes itself from siblings by explaining how it connects to betfair_market_prices, making its role in the hierarchy explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool: to navigate the sport/group/event/market hierarchy. It explicitly directs the user to 'Feed market ids into betfair_market_prices,' demonstrating integration with a sibling tool. However, it does not explicitly state when not to use it or compare with other navigation-related siblings like betfair_markets_by_event, so it lacks full comparative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betfair_scoresA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful behavioral details: the return structure (top-level array with eventId, eventTypeId, score object) and the fact that no authentication is required. This goes beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: one purpose sentence, a return type snippet, and an auth note. Every part adds value, and the structure is front-loaded with the most important information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only, idempotent lookup tool with full schema coverage and no output schema, the description provides sufficient context: it states what events it covers, gives the return shape, and notes auth requirements. It could mention pagination or rate limits, but these are not critical for selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all parameters (_ak, alt, locale, eventIds). The description's phrase 'one or more in-play events' aligns with eventIds but adds no new parameter-specific semantics beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Live scores for one or more in-play events (per-sport score detail)'. It uses a specific resource and scope, and the mention of 'per-sport score detail' distinguishes it from sibling tools like betfair_scores_broadcast and betfair_event_timelines.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly notes this is for 'in-play events', giving clear context for when to use it. It does not name alternative tools or exclusions, but the use case is unambiguous given the sibling set (e.g., betfair_scores_broadcast for broadcast feeds).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_pop_sgm_bet_dataA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds the return shape (PopSGMBetItems with legs/price) and explicitly confirms no authentication is needed, which is useful behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise (three short sections) and front-loaded with the core purpose. Every sentence earns its place: purpose, return structure, and auth requirement. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 explicitly showing the return format. It covers the essential usage context (one master event, no auth) and the parameter schema is complete. Minor gaps like pagination or sorting behavior are not critical for a simple read-only tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for all three parameters (SortOrder, CategoryId, MasterEventId). The description adds no additional parameter-level detail beyond the schema, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns 'Popular Same Game Multi suggestions for one master event', which is a specific resource and scope. It also provides the return structure, distinguishing it from sibling tools like betr_pop_sgm_category that may target categories rather than master events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly indicates this is for a single master event, implying you need a MasterEventId, and states 'Auth: none needed.' While it doesn't explicitly exclude alternatives or mention sibling tools, the context is clear and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• chesscom_archivesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the agent knows it's a safe read operation. The description adds the output format ({archives:[url]}) and the meaning of the last entry, enriching behavioral context beyond the annotations. It also notes that no authentication is needed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded, with a clear purpose, return format, example, and auth note in a few sentences. Every sentence contributes useful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple one-parameter tool, the description covers the core aspects: purpose, usage, return format, and auth. No output schema exists, so explaining the return structure is valuable. It is complete enough for selection and invocation, though it could optionally mention error behavior for invalid usernames.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes the username parameter as required and part of the URL path, covering 100% of parameters. The description only adds an example value ('hikaru') but no additional semantic detail, so it meets the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists monthly game archives for a player, using a specific verb and resource. It distinguishes itself by explicitly saying to call this before asking for a month's games, which differentiates it from chesscom_monthly_games.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs to call this tool before fetching a month's games, providing clear timing context. It also shows how to extract the most recent month from the last archive URL. However, it does not name alternative tools or explicitly state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketaustralia_playersA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond the annotations by disclosing the exact return shape and noting 'Auth: none needed.' Since the annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, the additional return-structure and authentication context earns a solid score without needing to repeat safety flags.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is efficient and front-loaded: the first sentence states the core function, followed by a concise instruction and a structured return example. It avoids redundant filler and every sentence serves a purpose (purpose, input, return, auth).

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only batch lookup, the description covers the essential context: what it does, how to specify input, the response format, and authentication. Minor gaps exist—no mention of batch size limits or detailed error handling—but these are not critical for the tool's straightforward use case.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage of all three parameters with descriptions (format, jsconfig, playerIds). The description's 'Pass a list of playerIds' adds no new semantic info beyond what the schema states; it only reinforces the required parameter. No additional meaning is provided for format or jsconfig beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Player profiles for a batch of player ids' and lists the specific fields returned (name, DOB, birthplace, batting/bowling hand + type, height, image). This specific verb+resource definition distinguishes it from other cricket tools that handle fixtures, scorecards, or competitions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by stating 'Pass a list of playerIds' and explaining where those IDs come from: 'Ids come from a scorecard's players[] or fixtures.' This helps the agent construct correct calls, though it doesn't explicitly mention when not to use this tool or suggest alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketdata_match_infoA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context: it reproduces the return shape, explicitly warns that the shape is unverified and approximate, advises inspecting the live payload, and states the API key requirement. This goes beyond redundant annotation repetition.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: purpose, return shape, caveat, example, and auth are each distinct and front-loaded. Every sentence carries information, and the caveat about vendor documentation is important and honestly presented. No filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter lookup, the description covers the core purpose, input format, expected output shape, authentication, and an unverified-data warning. It does not mention error handling or live vs. historical match status, but the provided shape includes status/type fields, mitigating that gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% — the single 'id' parameter already has a clear description ('Match id (from a match list).'). The tool description does not add additional semantics beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'One match: toss, venue, teams and result,' which clearly specifies a single-match lookup with a identifiable set of fields. It distinguishes itself from sibling tools like cricketdata_matches (lists) and cricketdata_scorecard (detailed scorecard) by scope and content.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'One match' plus the example with an id implies the tool is used when you already have a match id (e.g., from a match list). The context is clear, but no explicit alternative or when-not-to-use guidance is given relative to sibling match-related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_hist_matchupsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds valuable context: the return structure (book, event_id, event_name, event_completed, matchups array with open/close odds) and an explicit authentication requirement ("Auth: needs your own key in DATAGOLF_KEY"). These go beyond the structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence purpose, a return shape snippet, and an auth note. Every element adds value and is front-loaded. No redundant prose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only historical data tool with 6 parameters (100% schema coverage) and no output schema, the description provides the essential return structure and auth requirement. It does not explain how to find event_id or mention pagination, but the sibling datagolf_hist_event_list likely covers that. Overall, it is sufficient for a well-specified API.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter already has a description in the schema. The description adds minimal extra semantics beyond "from one sportsbook" which relates to the book parameter. No additional parameter-level guidance is provided, matching the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description begins with a specific verb phrase "Historical matchup / 3-ball odds for a past event from one sportsbook," clearly identifying the resource (historical matchups/3-ball odds) and scope (past event, one sportsbook). This distinguishes it from siblings like datagolf_matchups (presumably current) and datagolf_hist_outrights (different market type).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly frames usage for "historical" and "past event" data, which implies it is not for current/live matchups. It does not explicitly name alternative tools, but the temporal scoping provides clear context for when to use it. No exclusions are stated, but the context is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_hist_results_event_listA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, idempotent, and openWorld hints. The description adds valuable context beyond this: the required authentication via DATAGOLF_KEY and the top-level array return shape, which helps set expectations for invocation and output handling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact with clear labeling: main purpose, return format, and auth requirement. Each sentence earns its place, and the most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with no required parameters and full schema coverage, the description supplies the essential missing context: the return shape (list of event objects with fields) and the auth requirement. It's adequate for an agent to invoke it correctly, though it doesn't mention potential pagination or sorting, which would be nice but not necessary.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters ('tour' and 'file_format') already documented with defaults and constraints. The description adds no additional parameter-level information, so it relies entirely on the schema – consistent with the baseline for full coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it lists tournaments with historical event-level results data and explicitly identifies itself as the ID lookup for datagolf_hist_results. This makes the tool's purpose and distinction from related data-retrieval siblings evident.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides a clear usage context (ID lookup for datagolf_hist_results) but stops short of explicitly stating when-not to use it or listing alternatives. The implied workflow is clear enough for an agent to understand when to call this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_in_playA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable context: authentication requirement (DATAGOLF_KEY) and the return shape with sample fields. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-line summary, a return type example, and an auth note. Every sentence adds useful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only data retrieval tool with no output schema, the description covers the essential aspects: purpose, return format, and authentication. It could mention behavior when no live tournament exists, but given the simple parameter set and annotations, it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with each parameter described adequately (tour, file_format, odds_format). The description does not add further meaning to these parameters beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides live (in-play) model predictions during a tournament, specifically current position/score and updated win probabilities. This distinguishes it from sibling tools like datagolf_pre_tournament and datagolf_live_strokes_gained by focusing on in-play predictions and probability updates.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context that this is for live/in-play tournament usage, implying it should be used when a tournament is ongoing rather than pre-tournament. It does not explicitly name alternatives or exclusions, but the 'Live (in-play)' phrasing and 'during a tournament' signal when to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_pre_tournament_archiveA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context by disclosing the return structure and the auth requirement (DATAGOLF_KEY). It also clarifies the predictions are 'what the model said beforehand,' which adds meaning 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, with three short sentences covering purpose, return format, and auth. Every sentence provides essential information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 specifying the return structure. It also covers auth requirements. However, it does not explain how to locate event_id for past events or how odds_format affects the output, though those details are in the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 five parameters. The description does not add additional semantic context beyond the return structure and auth note, so it meets the baseline but does not exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Archived pre-tournament predictions for a past event,' which specifies the action (archived predictions), the resource (pre-tournament data), and distinguishes it from the current-event tool (datagolf_pre_tournament).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for a past event' provides clear context that this tool is for historical data, implying it should not be used for current events. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entain_racing_searchA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds 'Auth: none needed' and a precise return shape, which provide useful behavioral context beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately concise—two sentences plus a compact return sketch. It is front-loaded with the core function and avoids any redundant or filler text, making every element valuable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 explicitly stating the return structure and auth requirements. It covers the essential operational details for a simple search tool with two optional parameters, though it leaves some minor gaps around bucket contents or pagination.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents both parameters ('q' and 'category_ids'). The description mentions 'optional full-text' but adds no new semantic detail beyond the schema, meeting the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Racing search facets (barrier/country/jockey/trainer buckets); optional full-text.' This specifies a distinct verb ('search') and resource ('racing facets'), and the listed facets distinguish it from sibling racing tools like entain_racing_racecard.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: this tool is for searching with facet buckets and optional full-text. It does not explicitly name alternatives or state when not to use it, but the focused scope and returned structure imply appropriate use cases, earning a solid 4.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entain_sport_event_requestA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, idempotent, and open-world hints. The description adds transparency by disclosing the exact return structure (events, markets, prices, entrants, next_events, regions) and explicitly stating 'Auth: none needed'. This is useful behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: the main purpose is in one sentence, followed by a compact return structure and auth note. Every piece of information earns its place, with no wasted words. The formatting is clean and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has one parameter and no output schema, but the description covers the purpose, the accepted input, the return keys, and authentication. It doesn't describe the nested structure of the return objects, which would be helpful but is not strictly necessary for a single-parameter bulk fetch tool. Given the lack of an output schema, listing top-level keys adds meaningful completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes the single parameter category_ids as a JSON array of sport category UUIDs (100% coverage). The description adds only that it accepts 'one or more' categories, which is implied by the schema. No additional parameter meaning is provided, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: it fetches bulk events, markets, and prices for one or more sport categories. It names the specific resource (sport categories) and the content type (events, markets, prices), and distinguishes itself from narrower sibling tools like entain_sport_event_card by emphasizing the bulk scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use this for bulk data across one or more sport categories. It doesn't explicitly name alternatives or exclusions (e.g., 'for single events use entain_sport_event_card'), but the bulk scope is evident enough to guide selection among the many sports data siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_pro_teamsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, and the description does not contradict these. It adds valuable behavioral context: auth behavior ('works without a key; ESPN_FANTASY_COOKIE unlocks more'), a special team id (id 0 = free-agent/none), and the data structure with 33 NFL entries. This goes beyond the annotations without being excessive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: a one-line purpose, a returns block with structure, an example, and an auth note. No filler sentences; every line contributes. It is front-loaded with the main purpose, making parsing and understanding effortless.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 providing a concrete return shape, a note about team count (33 entries for NFL), and a special case (id 0). It also mentions auth needs. It could be slightly more complete regarding non-NFL sports or variations in proGamesByScoringPeriod, but the essentials for correct invocation and interpretation are covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%; every parameter is already described in the input schema (game enum, view default, required seasonId). The description adds an example binding game='ffl' and seasonId=2025, which helps illustrate valid input but does not explain parameter semantics beyond 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Pro (real-world) teams for a fantasy season' with a specific verb and resource scope, distinguishing it from fantasy-team-centric sibling tools like espnfantasy_teams. It enumerates exactly what is returned (ids, abbreviations, BYE weeks, games by scoring period), leaving no ambiguity about the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context for use (fetching real-world pro teams and schedules for a fantasy season) with an explicit example ('NFL teams + bye weeks + week-by-week pro schedule'). It does not explicitly name alternatives or exclusion criteria, but the 'Pro' designation and sibling contrast make appropriate usage clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_scoreboardA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context about authentication (works without a key; cookie unlocks more) and the return structure, which goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Well-structured with a one-line summary, Returns block, Example, and Auth note. Every section earns its place, and the description is front-loaded with the purpose. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description compensates by providing a return shape and example. It covers authentication and main parameters. It could further clarify what 'pro-game state' includes, but overall it is sufficiently complete for a read-only tool with good annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers all parameters (100% coverage), so baseline is 3. The description adds a concrete example with parameter values and clarifies the meaning of scoringPeriodId ('omit for the current one' is in schema, but the example reinforces it). This adds useful context beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states it is a scoreboard for a scoring period, providing matchup totals and pro-game state. This distinguishes it from sibling tools like espnfantasy_matchups or espnfantasy_boxscore by focusing on the scoreboard view with aggregate totals.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context (scoring period scoreboard) but offers no explicit guidance on when to use this tool versus alternatives like espnfantasy_matchups or espnfantasy_boxscore. The example implies usage for 'this week's scoreboard' but does not address exclusions or sibling distinctions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_transactionsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, open-world, and idempotent behavior. The description adds valuable context: auth requirements ('works without a key; ESPN_FANTASY_COOKIE unlocks more if set') and the return shape. This goes beyond the structured data without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: purpose, return format, example, and auth note. Each section serves a purpose with no filler. The front-loaded purpose sentence is immediately informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description provides the return structure, an example, and auth notes. It's sufficient for a read-only list tool, though it doesn't mention potential pagination or error behaviors. Overall, it's a complete enough description for the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds a usage example with default parameter values but doesn't introduce new semantics beyond what the schema already provides for parameters like game, leagueId, or scoringPeriodId.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Completed transactions (adds, drops, trades, waiver claims) for a scoring period', clearly identifying the resource and scope. This distinguishes it from the sibling tool espnfantasy_pending_transactions by explicitly saying 'Completed'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: for completed transactions in a scoring period, and provides a concrete example. It doesn't explicitly name alternatives (like espnfantasy_pending_transactions), but the 'Completed' qualifier makes the usage context unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espn_newsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover safety (readOnlyHint, idempotentHint) and open world. The description adds valuable behavioral context: return format ({header, articles}), content fields (headline, description, links, images), and 'Auth: none needed'. It doesn't mention rate limits or failure behavior, but with annotations and a simple read-only feed, this is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely efficient: one lead sentence stating purpose, one line for return format, one snippet example, and a one-line auth note. Every sentence earns its place. No fluff, front-loaded purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple read-only news feed with full parameter coverage and strong annotations. The description covers return structure, example usage, and auth. No output schema needed since return format is explicitly defined inline. It's complete for an agent to select and invoke.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with descriptions (sport slug, league slug, limit). The description adds a concrete usage example ('sport': 'football', 'league': 'nfl') that demonstrates exact parameter values, reinforcing the schema's 'e.g.' hints. It doesn't add syntax details but the example meaningfully aids correct invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this is a 'League news feed' returning 'recent articles' for one league, which distinguishes it from score/standings/team tools like espn_scoreboard or espn_teams. However, it doesn't explicitly differentiate from other news tools like pl_news_latest or nbl_news, so it's clear but not fully sibling-distinguishing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it's for one league's news, with an example showing sport/league values. It doesn't explicitly state when to use this over alternatives or exclude other uses, but the 'for one league' scope and example give solid contextual guidance. No misleading alternatives are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fanduel_sb_live_scoreA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnly, openWorld, and idempotent. The description adds 'Auth: none needed' and specifies the exact return structure (openDate, homeTeam/awayTeam objects, comp, mediaTypes). The 'NJ' restriction is also disclosed. This is useful behavioral context beyond annotations with no contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise lines: purpose, return shape, and auth. Front-loaded with the most important info. No filler or repetition. Each sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with strong annotations, the description provides the return shape, auth, and geographic limitation. It doesn't explain period state values or mediaTypes, but that's unnecessary for selection and invocation. The combination of schema, annotations, and description is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for eventId, including its origin from fanduel_sb_call and URL path requirement. The description itself does not elaborate on the parameter, and the schema already carries the semantic weight. Baseline 3 is appropriate since the schema is sufficient and the description adds no extra parameter nuance.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool provides 'Live score + period state for one sportsbook event (NJ)'. This is a specific verb+resource with a geographic scope, distinguishing it from sibling tools like fanduel_sb_call and other sportsbook tools. The 'one event' qualifier directly maps to the eventId parameter.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Use is implied by the purpose: when you need live score for a single sportsbook event. The schema description further guides usage by stating eventId comes from 'fanduel_sb_call event_page / content_page', and the tool description references the return shape. This provides a clear workflow context, though it doesn't explicitly list exclusions or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• footballdataorg_matchA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond annotations by explicitly stating the need for a key (403 without), providing a detailed return shape, and warning that the shape is from vendor docs and unverified. This gives the agent critical caveats about data reliability. It does not contradict any annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose and key requirement, then uses labeled sections for return shape, example, and auth. The detailed return shape is justified given there is no output schema, so the length is warranted. It is well-structured and avoids redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema, the description provides all necessary context: purpose, parameter, example, auth, return shape, and a caveat about verification. This fully equips an agent to invoke the tool and handle the response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema already provides 100% coverage with a description of matchId as required and part of the URL path. The description adds an example usage but no additional semantic meaning. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states 'One match with lineups, goals, bookings and head-to-head' which clearly identifies the resource (a single match) and the data returned. This distinguishes it from sibling tools like footballdataorg_matches which return multiple matches. It uses a specific resource and scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use for a single match via 'One match' and provides an example with matchId. It also notes the auth requirement. However, it does not explicitly state when to prefer this tool over sibling tools such as footballdataorg_matches or footballdataorg_competition_matches, nor does it mention exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• footballdataorg_standingsA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly, openWorld, idempotent), the description discloses critical behavior: 'NEEDS A KEY (403 without)' and 'Auth: needs your own key in FOOTBALL_DATA_ORG_KEY.' It also warns that the return shape is from vendor docs and unverified, and explains how to interpret the standings list (pick type == 'TOTAL'). This adds significant context for safe and correct invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the core purpose, followed by return shape, notes, example, and auth. However, the key requirement is stated twice ('NEEDS A KEY' and 'Auth: needs your own key'), which is mildly redundant. Overall, it is concise and every other piece of information earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description compensates with a detailed return shape, a caveat about unverified shape, an example, and authentication instructions. It fully covers the needs for an agent to select and invoke the tool correctly, including how to handle the standings list structure.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with descriptions for all three parameters (competition, season, matchday). The description adds only an example (competition: 'PL') and does not introduce new meaning beyond the schema. Per the baseline for high schema coverage, a score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'League table for a competition,' which clearly identifies the resource and its purpose. It is further clarified by an example ('Premier League table') and the detailed return shape showing standings. This distinguishes it from other footballdataorg tools and general standings tools by explicitly naming the resource type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through an example ({"competition": "PL"}) and notes the auth requirement, but it does not explicitly state when to use this tool versus alternatives like pl_standings or other provider standings. There is no exclusion guidance or mention of specific scenarios where this tool is preferred.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• formulae_team_standingsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only and idempotent behavior, so the description is not required to repeat that. It adds value by disclosing the return format, explicitly stating 'Auth: none needed,' and providing a concrete example, which goes beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured, front-loading the purpose in the first sentence, followed by return format, an example, and auth requirement. Every sentence contributes useful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with a single parameter, the description is quite complete: it explains the return shape, provides an example, and notes the auth requirement. The only minor gap is not explicitly pointing to formulae_championships for obtaining the championshipId, but the tool name and sibling context make this inferable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents championshipId as a required string uuid with 100% coverage, so the baseline is 3. The description provides an example value but adds little additional semantic meaning beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states this returns teams' championship standings with per-race points breakdown. The verb 'standings' and resource 'teams' are specific, and it explicitly distinguishes from driver standings by naming 'teams' and providing the return structure.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this is for team standings and notes it's the closest thing to race results, which guides selection when race-level data is needed. However, it doesn't explicitly name alternative tools like formulae_driver_standings or state when not to use this, so it stops short of full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_manager_historyA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark read-only and idempotent; description adds auth behavior ('works without a key; FPL_SESSION_COOKIE unlocks more if set') and edge case (current empty before GW1). These go 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Structured with a summary line, return schema, notes, example, and auth. Dense but every line earns its place; no fluff. Slightly long but justified by lack of output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-param read tool with no output schema, the description provides full return shape, interpretation of chips, and auth requirements. Complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers managerId 100% with description; the tool description repeats the required param in an example but doesn't add new semantic detail. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly identifies the resource: 'A manager's gameweek-by-gameweek history, past seasons, and chips already used.' It specifies the scope and distinguishes from sibling tools like fpl_manager_picks by focusing on history and chips, not current picks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: explains that chips shows what has already been played, which lets the user infer availability, and notes that current is empty before gameweek 1. However, it doesn't explicitly name alternative tools or state when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_candlesticksA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the agent knows it's a safe, idempotent read. The description adds the return format and auth requirement, which is useful context. It doesn't disclose potential rate limits or pagination behavior, but given the strong annotations, the added value is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences long, front-loaded with the purpose, then return format and auth. Every sentence earns its place, and there is no fluff or redundant wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only data tool, the description provides the core information: purpose, scope, return shape, and auth. It does not state time-window limits or pagination behavior, but given the straightforward nature and rich annotations, the gap is minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, meaning each parameter is already documented with descriptions. The description adds no additional parameter semantics beyond what the schema provides (e.g., period_interval mapping is already in the schema). Per the rubric, baseline 3 applies when the schema carries the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns OHLC price candlesticks for one market over a time window, with 1m/1h/1d periods. The phrase 'one market' distinguishes it from the batch sibling, and the tool's scope is specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description notes 'Auth: none needed,' which is a practical usage guideline. It also cross-references 'polymarket_price_history' as an alternative use case. However, it doesn't explicitly state when to prefer this tool over kalshi_candlesticks_batch or other siblings, so it lacks an exclusionary note.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• laliga_matchesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only/idempotent behavior. The description adds valuable context: the mixed-bag behavior of subscription alone, the return field structure, and auth requirements. It does not contradict annotations, though it leaves the 'more' unlocked by the key unspecified.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence contributes: what it does, the critical parameter warning, return format, a concrete example, and auth note. Well-structured with clear formatting for the example.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list endpoint with generous annotations and schema coverage, the description provides the return structure, example usage, auth notes, and behavioral caveats. No output schema exists, so the return-field list is essential and included.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema already documents all parameters, but the description adds the critical caveat that subscription alone returns mixed data and clarifies that competition=primera-division yields the full 380-match set. This compensates beyond schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies the tool as a 'Matches feed' and details that it returns LaLiga matches with specific competition slugs, making its purpose clear. However, it does not explicitly differentiate from sibling tools like laliga_match (singular) or other leagues' match feeds, 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: the IMPORTANT note instructs users to pass competition= for real competition matches and warns that subscription= alone returns mixed results. Includes a concrete example for a matchweek, but no explicit 'when not to use' or alternative tool references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lichess_leaderboards_allA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide read-only and idempotent hints. The description adds useful context by stating that no authentication is needed and by disclosing the Top 10 limitation and the return structure, which go beyond what 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose. It includes a purpose statement, return shape, example, and auth note, though the example line is slightly redundant with the first sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only tool with no output schema, the description covers all necessary aspects: purpose, return format, example, and authentication. It is sufficiently complete for an agent to invoke and interpret the result correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is no parameter detail to provide. The baseline for zero-parameter tools is 4, and the description correctly abstains from irrelevant parameter info.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns the top 10 for every time control and variant in one call. It uses a specific verb and explicit resource scope, and distinguishes itself from the sibling lichess_leaderboard by emphasizing the comprehensive single-call nature.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through phrases like 'in a single call' and 'Every leaderboard at once,' but it does not explicitly mention alternatives or when not to use this tool. It provides context but lacks explicit when-to-use versus when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_awards_listA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, covering safety. The description adds the return shape and 'Auth: none needed', providing useful behavioral context beyond annotations. No contradictions exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, with exactly two sentences: one for purpose and one for return/auth. It is front-loaded with the main purpose and contains no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple catalogue lookup with no output schema, the description provides the return structure, notes auth is not needed, and implies completeness ('every awardId'). Minor gaps like parameter combination behavior are not critical, making it complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes both parameters (sportId and leagueId) with defaults and examples, so schema coverage is 100%. The description does not add parameter-level detail, but the schema already handles it, earning the baseline score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it is an 'Award definitions catalogue' and explicitly positions it as 'the id lookup for mlb_awards', which distinguishes it from the sibling tool mlb_awards. It also lists the fields returned, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'the id lookup for mlb_awards' indicates when to use this tool (to resolve award IDs) versus the related tool. While not as explicit as naming an alternative, it effectively guides usage. No exclusions are mentioned, but the tool's simple nature makes this adequate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_draftA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it read-only, open-world, and idempotent. The description adds value by disclosing that no authentication is needed and by providing the exact return structure, which is especially helpful given the absence of an output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, with the core purpose in the first sentence, return format in the second, and auth in the third. It is concise, front-loaded, and contains no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description includes the return shape, auth requirements, and the key filter option, which together with the thorough schema and annotations provides a sufficiently complete picture for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All four parameters have full schema descriptions (100% coverage), so the description does not need to compensate. It adds minor reinforcement with 'Filter by round' but does not introduce additional semantic nuance beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning MLB Rule 4 draft results for a given year, including specific pick details (player, school/team, position, signing info). It distinguishes itself from related tools like mlb_draft_prospects by specifying 'results' and 'for a year'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states the primary filter capability ('Filter by round') and implies the need for a year, providing clear context for use. However, it does not explicitly mention alternatives or when not to use this tool, so it falls just short of full exclusionary guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_game_changesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the return shape ({totalItems, dates:[{games:[{gamePk, gameDate}]}]}) and states 'Auth: none needed,' adding context beyond the annotations. It does not contradict the readOnlyHint, openWorldHint, or idempotentHint annotations, and the polling behavior is explicitly stated.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately concise: one purpose sentence, a return shape, and an auth note. All content is necessary, front-loaded, and free of filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with fully documented parameters and a return shape provided in the description. The only minor gaps are that it doesn't define what counts as a 'change' or mention any pagination/limits, but these are not essential for a minimal polling helper given the open-world hint and lack of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers all three parameters with descriptions and an example timestamp, achieving 100% schema description coverage. The description adds no additional parameter-level detail beyond restating the 'since a timestamp' concept, so the schema carries the semantic burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Games changed since a timestamp — a polling helper to detect updated games.' It uses specific verbs (poll, detect) and a specific resource (games changed since timestamp), and the polling helper framing distinguishes it from other MLB tools like schedule or score endpoints.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly labels it as a 'polling helper to detect updated games,' providing clear context for when to use it (repeated checks for game updates). It does not name alternatives or exclusions, such as when to prefer mlb_schedule or mlb_game_changes over related endpoints, but the use case is well implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_game_contentA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/openWorld/idempotent hints, the description adds useful behavioral details: it specifies the return keys ({editorial, media, highlights, summary, gameNotes}), states that auth is not needed, and notes that the box-score-and-storylines bundle is included only when present. This helps an agent understand the response shape and conditional data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, using two short sentences plus a return signature and auth note. It front-loads the core purpose and the return structure without any filler or redundant schema repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given a single documented parameter, no output schema, and strong annotations, the description provides a complete picture for a simple content-read tool. It includes the return keys and auth requirement, which compensates for the lack of an output schema. A slightly deeper explanation of the content structures would push it to 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents the only parameter (gamePk) with 100% coverage, including its type, requirement, and that it's part of the URL path. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: retrieving editorial/media content for a game, specifically naming highlights, recap, media, and the optional box-score-and-storylines bundle. It distinguishes this from statistical or live-feed tools by focusing on 'editorial / media content.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use the tool (when needing game editorial/media content) and what it returns, but does not explicitly mention alternatives or when not to use it. Since the domain is clear and distinct from sibling tools like mlb_boxscore or mlb_live_feed, no exclusions are stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_high_lowA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds value beyond annotations by specifying the return structure ({highLow:[...]}) and explicitly stating 'Auth: none needed.' It also clarifies the behavior as 'top and bottom performances,' providing useful behavioral context. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded. It opens with the core purpose, followed by the return shape and auth note, with no filler. Every sentence earns its place, and the structure is immediately scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 5 parameters, no output schema, and relies on annotations, the description is fairly complete. It provides the return shape, auth requirement, and a clear statement of what the tool does. It could elaborate on edge cases or parameter interactions, but the combination of schema coverage, annotations, and description is sufficient for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 five parameters, including descriptions for sortStat (with reference to mlb_meta) and orgType enum. The description does not add significant parameter-level detail beyond hinting at 'org level' and 'sortStat', but with full schema coverage, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns high/low stat records for an org level, specifically top and bottom performances for a sortStat in a season. It identifies the resource (stat records) and the operation (get high/low), and the included return shape further clarifies the purpose. This distinguishes it from sibling tools like mlb_leaders or mlb_stats by emphasizing 'high/low' and 'org level'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: when you need top and bottom performances for a sortStat at an org level in a season. It does not explicitly mention alternative tools or exclusions, but the scope ('org level', 'sortStat', 'season') is specific enough to guide an agent. The note 'Auth: none needed' also helps with practical usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_home_run_derbyA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly adds 'Auth: none needed,' which is behavior info not present in the annotations. It also outlines the return structure, offering transparency about the response shape. These additions provide useful context beyond the readOnlyHint, openWorldHint, and idempotentHint annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded, stating the purpose in the first line. The return structure is provided in a brief outline, and the auth note is a single clause. Every sentence adds value without unnecessary padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only one parameter, no output schema, and annotations indicating a read-only operation, the description provides sufficient context: purpose, parameter identification, return shape outline, and auth requirement. A more detailed breakdown of the nested matchups fields would be helpful but is not essential for a tool of this simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents gamePk with 'Derby game id. Required — part of the URL path,' giving clear semantic meaning. The tool description itself does not add further parameter details, so it does not exceed the baseline of 3 for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's function: retrieving the Home Run Derby bracket and results for a specific derby gamePk. This distinguishes it from sibling tools like mlb_schedule or mlb_boxscore by focusing specifically on the derby event and its unique game identifier.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for a derby gamePk' provides clear context for when to use the tool—when you have a derby game identifier and need bracket or results. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_linescoreA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint. The description adds the exact return shape, states 'Auth: none needed,' and clarifies it is for live games — useful behavioral context beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a concise summary, followed by a compact return-shape snippet and an auth note. No wasted words; every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with full schema coverage and no output schema, the description covers the return structure, auth, and live-game scoping. It is complete enough for an agent to use correctly, though it doesn't discuss edge cases like non-existent gamePk.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — both gamePk and timecode are already well-described in the schema. The description's return structure indirectly clarifies how parameters affect the result, but it adds no parameter-specific semantics, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns a game linescore with runs per inning, R/H/E totals, and current inning state. The resource is specific ('Game linescore') and distinct from sibling tools like mlb_boxscore or mlb_live_feed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for live games' provides clear context on when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_live_feedA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent traits; description adds 'Auth: none needed' and warns of the payload size with 'large'. This provides useful context about expectations beyond what annotations specify.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three compact lines with clear structure, no redundant phrasing. It front-loads the main purpose and quickly covers return value and auth.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description provides a breakdown of the return object and notes the feed's size. It is sufficiently complete for a complex API, though it could clarify when to prefer this over specialized endpoints.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All three parameters are documented in the schema with 100% coverage. The description adds no additional clarification for hydrate or timecode, and merely restates that gamePk is required via the return structure; baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly defines the tool's function: retrieving the complete MLB live game feed, combining gameData and liveData. It distinguishes itself from sibling MLB tools like mlb_boxscore or mlb_playbyplay by labeling itself 'the firehose' and 'complete'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys that this tool returns everything about a game, implying use when comprehensive data is needed. It doesn't explicitly name alternative tools or provide exclusion criteria, but 'complete' and 'firehose' provide clear context for when to choose it over more focused counterparts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_peopleA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the core behavior is covered. The description adds value by specifying the exact return structure and stating that no authentication is needed, which are useful behavioral details 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences: one for the main purpose, one for the return format, and one for auth. Every sentence provides useful information without redundancy, and the key purpose is stated first.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a batch player profile tool, the description covers the essential points: what it does, the input type, and the return format. It doesn't specify any limits on personIds array size or detailed hydrate behavior, but given the simplicity of the tool and existing schema descriptions, the description is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (both hydrate and personIds have descriptions), so the schema does the heavy lifting. The description does clarify that personIds is a list (matching the array type in schema) and gives an example for hydrate in the schema itself. The description adds minimal extra meaning beyond the schema, which is appropriate at baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches batch player profiles for a list of personIds, using a specific verb ('Batch') and resource ('player profiles'). It also distinguishes itself from the sibling tool mlb_player by explicitly calling it 'the multi-id form of mlb_player', which is a clear differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when you need multiple player profiles at once, referencing mlb_player as the single-id alternative. It lacks explicit when-not-to-use instructions, but the alternative is named and the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_people_changesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful behavioral context beyond the annotations: it discloses the return structure, notes that the response 'can be large for a wide window', and explicitly states 'Auth: none needed'. These details supplement the readOnlyHint and idempotentHint annotations, giving the agent a better sense of what to expect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: it states the core function in the first sentence, shows the return shape in a structured block, and includes a one-line auth note. Every sentence adds value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the essential contextual elements: it identifies the tool as a sync helper, specifies the return shape (important because no output schema exists), warns about response size, and states auth requirements. It does not explicitly mention alternatives or exclusions, but for a simple polling tool with high schema coverage and strong annotations, it provides sufficient context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides complete descriptions for both parameters (updatedSince as ISO timestamp, fields as trimming), so the description does not need to replicate that. It adds a small behavioral note about wide windows affecting response size, but does not introduce new parameter-level semantics beyond the schema. Thus, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly defines the tool as a polling/sync helper for player records changed since a timestamp, which distinguishes it from sibling tools like mlb_game_changes. It specifies the resource (player records) and the operation (retrieve changes), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly labels the tool as a 'polling/sync helper' and identifies it as the 'people-side sibling of mlb_game_changes', providing clear context for when to use it. It does not explicitly list exclusions or alternative tools, but the sibling reference and the 'changed since a timestamp' phrasing give a clear usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_schedule_postseasonA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds useful behavioral context beyond the annotations: it discloses the exact return shape (totalGames, dates with gamePk, seriesDescription, teams, status) and states 'Auth: none needed.' This complements the readOnlyHint and idempotentHint annotations rather than repeating them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: two sentences for purpose, a three-line return format, and an auth note. Every sentence earns its place without redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 providing a return structure. It also covers auth and optional filtering. A minor gap is the lack of explicit default behavior when season is omitted, but the tool is otherwise adequately specified for its simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so all four parameters are already described. The description's mention of 'optionally a single season / series type' maps to the season and gameTypes parameters but does not add significant meaning beyond what the schema provides. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns the postseason schedule ('all playoff games') and supports optional filtering by season or series type. This distinguishes it from sibling tools like mlb_schedule (regular season) and mlb_schedule_postseason_series (series-specific detail), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the primary use case: retrieve all postseason games, optionally filtered by season or series type. It does not explicitly exclude or reference alternatives, but the scope is clear enough that an agent would know when to select this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_sports_playersA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the return structure, a size warning ('large'), and auth requirements, complementing the readOnlyHint and idempotentHint annotations. It does not contradict annotations. However, it does not disclose pagination behavior or how the hydrate parameter affects the response, which would be useful.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, each with clear value: purpose, return shape/size, and auth. No redundant wording, and the most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The return structure and size warning compensate for the absence of an output schema. The tool is simple with strong annotation coverage, making it reasonably complete. Minor gaps include hydrate behavior and alternative tool references, but these do not undermine overall usability.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% parameter coverage, including sportId=1 for MLB and season year. The description repeats the sportId mapping but adds no new meaning beyond the schema. Baseline 3 is appropriate given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns all players for a sport/season, positioning it as a full catalogue for name-to-ID resolution. This differentiates it from narrower siblings like mlb_team_roster or mlb_player_search. The verb and resource are explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case (full catalog lookup for a season) with clear context, but does not explicitly mention alternatives or when not to use it. Sibling tools with similar player data are not referenced, so the guidance is implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_standingsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds 'Auth: none needed' and a detailed return structure, which is useful context beyond the annotations. No contradiction detected.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences plus a compact return format block. It front-loads the main purpose and includes a structured output example without redundant prose, earning full marks for efficiency.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description provides a return structure that is essential. It covers the core use case and auth. However, it does not explain how the 'standingsTypes' parameter might alter the output structure (e.g., when requesting 'wildCard' alone), leaving a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description only repeats the leagueId mapping already in the schema and does not add new meaning or clarify parameter interactions, so it stays at the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Division standings — per-team W/L, pct, GB, streak, run differential, wild-card and division ranks,' which clearly specifies the resource and data contents. The tool name 'mlb_standings' and the league ID mapping distinguish it from other standings tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by stating this is about MLB division standings and gives specific leagueId instructions. However, it does not explicitly mention alternatives or exclusions (e.g., 'for other sports use other standings tools'), though this is implied by the name and scope.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_statsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the bar is lower. The description adds value by specifying the exact return shape ({stats:[...]}), explicitly stating 'Auth: none needed', and mentioning sort/limit behavior. It does not contradict the annotations and provides useful behavioral context beyond the structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences covering purpose, return structure, and auth, all front-loaded and free of fluff. Every sentence contributes meaningful information, and the return structure is presented cleanly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a concrete return structure, effectively serving as a mini output schema. It also notes auth requirements. However, for an 8-parameter tool, it lacks details on default season behavior, how byDateRange works with other filters, or examples of common queries, which would help an agent invoke it correctly in varied scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 reiterates the group and type options and mentions sort/limit, but adds no new semantic detail beyond what the schema already provides for each parameter. It does not clarify interactions or default behaviors for parameters like season or sportId.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Season stats query across players' with a specific verb and resource, and enumerates groups (hitting/pitching/fielding) and stat types (season, career, byDateRange, ...). This distinguishes it from sibling tools like mlb_player_stats and mlb_leaders, making its purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this is for querying stats across players, with sort/limit for top-N tables, implying use for aggregate comparisons rather than single-player lookups. However, it does not explicitly name alternatives or exclusions, such as pointing to mlb_player_stats for individual player stats, so it lacks explicit when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_team_statsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it as readOnly, idempotent, and openWorld. The description adds useful behavioral context by providing the exact return structure and noting that no authentication is needed. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two short paragraphs covering purpose, return shape, and authentication. Every sentence earns its place, with the Returns block providing essential structural detail without wasteful elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description compensates by outlining the return structure. It covers team-level scope, grouping, stat types, and auth. It does not detail the nested 'stat' object, but the overview is sufficient for a moderate-complexity data retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 5 parameters. The description marginally reinforces the meanings of 'group' and 'stat type' but adds no new parameter semantics 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'One team's aggregate stats' and specifies the key dimensions: season, group (hitting/pitching/fielding), and stat type. It distinguishes from sibling tools like mlb_team (team info) and mlb_player_stats (player-level) by emphasizing team-level aggregate data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when you need aggregated stats for a single team across specified seasons and groups. It does not explicitly mention alternatives or exclusions, but the phrasing 'One team's aggregate stats' gives clear context compared to other team- or player-focused tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mysportsfeeds_gamesA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description provides substantial behavioral context beyond the annotations: a detailed return shape, a crucial note about the nested schedule/score structure, an explicit warning that the shape is unverified and approximate, and an authentication requirement. This goes well beyond the readOnlyHint/openWorldHint/idempotentHint annotations and does not contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear purpose sentence, a detailed return-shape block, important notes about structure and verification, an example, and an auth line. While the return shape block is lengthy, every sentence earns its place, and the information is dense without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 providing a full return shape, a caveat about unverified vendor documentation, an example invocation, and auth guidance. This gives an agent nearly all the context needed to safely and correctly invoke the tool, including a warning to inspect the live payload.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already gives comprehensive descriptions for all 5 parameters, including enums, URL path details, and formats for league/season. The description's example only repeats what the schema states and adds no new semantic meaning. With 100% schema coverage, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Games for a season in one league, with scores and venue,' which identifies the resource (games), the scope (season and league), and key data fields. This is distinct from sibling tools like mysportsfeeds_boxscore (single game) or mysportsfeeds_standings, making the purpose immediately clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for season-level game data with an example ('This NFL season's games') and notes authentication, but it does not explicitly state when to prefer this tool over alternatives such as mysportsfeeds_boxscore or mysportsfeeds_standings. Guidance is implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mysportsfeeds_player_gamelogsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds valuable caveats: the return shape comes from vendor docs and is unverified, and stats groups differ by sport. These disclosures go beyond the annotations and inform the agent that fields may not be reliable, which is critical for correct usage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized and front-loaded with a one-sentence purpose, followed by a clearly formatted return shape, a necessary caveat about unverified docs, a practical example, and an auth note. Every section earns its place: the return shape is essential given no output schema, the caveat mitigates risk, and the example aids invocation. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema and five parameters, the description provides substantial context: a return shape (albeit unverified), a usage example, auth requirements, and sport-specific stats note. However, it does not explain whether parameters like team and player can be combined, or how date filtering interacts with season, and pagination is not mentioned. These gaps are offset by the example and the caveat, making it sufficiently complete for basic invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for all five parameters (100% coverage), so the baseline is 3. The description enhances this with a concrete example showing league='nba', season='current', and team=['LAL'], illustrating how to filter by team. It also clarifies that league and season are part of the URL path, matching the schema descriptions, but the example adds practical usage context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Per-game statistics for players across a season', which is a specific verb+resource statement that clearly defines the tool's function. It distinguishes itself from sibling tools like mysportsfeeds_boxscore and mysportsfeeds_games by focusing on season-wide per-game player logs. The additional return shape and example reinforce the purpose without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving player game logs but does not explicitly state when to use this tool versus alternatives. The phrase 'the cleanest surface this API has' hints at superiority, but there is no direct comparison or exclusion of other mysportsfeeds tools. An example call is provided, but no guidance on when not to use this tool or which sibling to choose instead.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nba_playbyplayA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to restate safety. It adds value by describing the return structure, the CDN source, and that no authentication is needed. This goes beyond the annotations and provides useful behavioral context without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and concise: a clear definition, a returns object, a concrete example, and auth note. Every sentence serves a purpose with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter, read-only tool, the description is complete. It explains the return format with nested fields, provides a usage example, and mentions authentication requirements. No critical information is missing for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the single parameter gameId with format and required status. The description supplements this by stating where to obtain the gameId from other NBA tools, which adds practical semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides an 'Event-level play-by-play log for one game' with every action including clock, score, player, and description. It is specific about the resource and scope, and references where to obtain the gameId, which distinguishes it from schedule/scoreboard tools. However, it does not explicitly compare against nba_boxscore, 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states 'gameId from nba_scoreboard_today / nba_schedule', giving clear guidance on how to obtain the required parameter. This implies the tool is for retrieving play-by-play for a known game. It does not explicitly mention when not to use it, but the context is well-established by the source reference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_newsA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (read-only, idempotent, open world), the description adds crucial behavioral context: it returns a raw array rather than an envelope, defaults to ~200 articles, and states 'Auth: none needed.' This enriches the agent's understanding of what to expect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear opening, a returns section, an example, and an auth note. It is slightly redundant (field list appears twice), but the content is relevant and front-loaded, so it earns a 4.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description provides a full breakdown of the return fields, an example call, the raw array format, and authentication requirements. It fully describes the tool's behavior and the single parameter, making it complete for a simple list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides a complete description of the `limit` parameter, including default behavior. The description repeats this ('Use `limit` to cap rows') and gives an example, but adds no new semantic meaning beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns NBL news articles, which is a specific resource. It lists the exact fields and notes the raw array format, making the tool's purpose unambiguous and distinct from other news-related siblings by its NBL scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for fetching latest NBL news but does not explicitly compare with alternatives or state when not to use the tool. The only guidance is to use `limit` to cap rows, which is more parameter usage than tool selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_player_boxscoresA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, lowering the burden. The description adds 'Auth: none needed' and the return structure, providing useful context beyond annotations. However, it does not mention rate limits or pagination, which are common behavior details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured, front-loading the core purpose in the first sentence. It includes a return format example and auth note, each earning its place without unnecessary verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with clear annotations and schema. The description explains the output shape and scope, but lacks details on what 'period' means or how seasonType affects results. Given the absence of an output schema, the included return structure is helpful, but a bit more context on the period field would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 tool description itself does not add parameter semantics beyond what the schema already provides, such as the year offset explanation and playerId source. Since the schema fully documents the parameters, no additional description is necessary.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Game-by-game box scores for one player across a season' with specific stats listed (points, rebounds, assists, etc.). It also distinguishes itself from siblings by noting 'The score-series / game-log source', which differentiates it from aggregate stats tools like nbl_player_stats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool ('game-log source', 'per match' granularity) but does not explicitly name alternatives or exclusions. It provides enough context for an agent to infer that this is for per-game data rather than season totals, but lacks a direct 'use this instead of X' statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_player_statsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only and idempotent behavior, and the description adds context by specifying the return structure ({type, count, data:[...]}), the exact fields, and that no auth is needed. This goes beyond the annotations, although it does not cover edge cases like empty data or season scope.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, uses a clear list of stats, and includes a compact return shape. Every sentence serves a purpose: the purpose, the parameter source, the return structure, and auth. No unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only tool, the description covers the purpose, parameter origin, return fields, and auth. It does not specify which season (current or a particular season) or pagination, but the given return structure and simple interface make it sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema's playerId description includes 'Player id (UUID) — from nbl_players[].player.id'. The description repeats this source ('playerId is the player UUID from nbl_players') but adds no new meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool returns season statistics for one player, listing specific data points (points, rebounds, assists, blocks, steals, turnovers, shooting splits, fouls, minutes). It clearly differentiates from siblings like nbl_player_boxscores by specifying 'season statistics' rather than per-game box scores.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use this for a single player's season stats, and it tells the agent to obtain playerId from nbl_players. It does not explicitly contrast with alternatives like nbl_player_boxscores or nbl_stat_leaders, but the phrase 'for one player' plus the data list implies the appropriate use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opendota_player_heroesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint, and the description does not contradict these. It adds useful behavior context by specifying the return format, ordering by games played, and the need to join hero_id via opendota_heroes, which is beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and well-structured, starting with a one-line purpose, followed by return format, an example, and auth note. Every sentence adds value, and the example is practical. It is front-loaded with the core purpose, making it easy for an agent to scan quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description provides the return fields and ordering, which is helpful. It also includes the join hint for hero_id. However, it does not explain the semantics of fields like with_games/against_games or how limit affects the aggregation, leaving some ambiguity for a complete understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema coverage is 100%—both parameters (account_id and limit) have descriptions. The tool description does not add extra parameter meaning beyond the schema, but the schema itself is sufficient. The limit parameter's effect on the returned hero list is only partially implied ('Restrict to the most recent N matches'), and the description does not clarify this further.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Which heroes a player uses and how they perform on each.' This is specific to hero performance per player, distinguishing it from sibling tools like opendota_player_matches (individual matches) or opendota_player_winloss (overall win/loss). The example 'Hero pool' reinforces the intended use.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool by stating it returns hero performance data for a player and includes an example invocation. It does not explicitly exclude alternatives or mention when not to use it, but the purpose itself is sufficiently clear for most selection scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opendota_public_matchesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful behavioral context beyond the annotations: it notes this is a 'sample' of recent matches (not exhaustive), lists the exact return fields, and clarifies the data contains 'hero ids only, no player identity'. It also states 'Auth: none needed'. No contradiction with annotations is present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence purpose, a return-format line, a minimal example, and an auth note. Every line earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only public data tool with two optional filters and no output schema, the description provides the return structure, the sample nature, and authentication status. It could mention pagination behavior or default ordering, but the schema covers the main parameters and the description is sufficient for a typical agent invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters (min_rank and less_than_match_id) fully described in the schema. The description does not add further parameter details, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'a sample of recent public (non-professional) matches', explicitly distinguishing it from professional play ('the ladder meta rather than the pro scene') and from sibling tools like opendota_pro_matches. It also provides the exact return shape, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for public/ladder match data rather than professional matches, giving clear context. It does not explicitly name alternative tools or state when not to use it, but the 'rather than the pro scene' phrasing effectively communicates the boundary.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opendota_teamsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already communicate read-only, idempotent, and open-world nature. The description adds valuable behavioral context beyond that: approximate response size (~250 KB), ordering by rating, field structure, and the fact that no authentication is required. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the main purpose. Every sentence serves a purpose: the first line states what it is, the second line details the return format, the example clarifies usage, and the auth line addresses access. No redundancy or unnecessary jargon.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple zero-parameter list tool with no output schema, the description adequately covers the return fields, ordering, size, and auth. It could perhaps mention pagination or the specific Dota 2 context, but the tool name and 'Professional teams' suffice. The provided information is sufficient for an agent to invoke and interpret the result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the input schema is empty. According to the baseline for 0-param tools, a score of 4 is appropriate. The description doesn't need to explain parameters, though it does provide useful output details which are not parameter-related.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning professional Dota 2 teams ranked by rating, with fields for win/loss records. The resource (teams) and the specific ordering/scope are explicit, and it distinguishes itself from sibling opendota tools (e.g., heroes, leagues) by focusing on teams and ratings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a use case through the example 'Pro teams by rating' but does not explicitly state when to choose this tool over alternatives or provide exclusions. No sibling comparison is made, leaving the agent to infer that this is the go-to for team ratings from OpenDota.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_intervalsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds context beyond the readOnly/openWorld/idempotent annotations: it explicitly states 'Auth: none needed' and describes the live, sampled nature of the data. It also discloses the return format as a top-level array. No contradiction with annotations is present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: one sentence for purpose, one for return shape, one for auth. Every line adds value without filler, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with rich schema annotations, the description covers the essential invocation context: what data is returned, that it is sampled over time, and that no auth is needed. It does not mention pagination or volume warnings, but the schema's 'high-volume' note for driver_number partially covers this, and the description is otherwise sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 does not add meaning to the parameters beyond what the schema already provides (e.g., 'Race session key, or latest.'). It only lists the output fields, not parameter syntax or semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Live gap data during a race — each driver's gap to the leader and interval to the car ahead, sampled over time.' This uses a specific verb+resource and explicitly names the unique output metrics (gap_to_leader, interval), distinguishing it from sibling tools like openf1_laps or openf1_position that return different data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool ('during a race', for live gap and interval data), but it does not name alternative tools or state explicit 'when not to use' guidance. The schema's note that driver_number is 'strongly recommended — this feed is high-volume' is a parameter-level usage hint, not a tool-selection guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_session_resultA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare this as read-only, idempotent, and open-world. The description adds valuable context: the exact return shape (array of objects with named fields), the auth requirement ('none needed'), and the presence of DNF/DNS/DSQ flags, which go beyond the annotation safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tightly composed: one main clause, a return-type line, and an auth note. Every sentence earns its place, and the most important information (what it returns) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only data fetch with rich annotations and a fully described schema, this is nearly complete. It covers purpose, return shape, and auth. It does not mention rate limits or pagination, but these are not essential given the annotations and the tool's simple output shape.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear descriptions for all four parameters, so the schema does the heavy lifting. The description contributes little beyond stating the return fields and does not add meaning to the parameters (e.g., behavior of 'latest' or filtering semantics) that isn't already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Final classification of a session' — a specific verb+resource that clearly identifies the tool's function. It enumerates the key data (position, laps, points, DNF/DNS/DSQ flags) and distinguishes it from sibling tools like openf1_starting_grid.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes it clear this is for final session results and implies you need a session_key. It does not explicitly state when not to use it or name alternatives, but the context is unambiguous enough for an agent to select it for session classification data.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_sessionsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the return format (top-level array with specific fields) and explicitly states no auth is needed, which is useful beyond annotations. It does not mention rate limits or pagination, but for a read-only list endpoint this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: a one-line purpose, then return format, then auth note. No filler; every sentence conveys actionable information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with 100% schema coverage and annotations, the description is sufficient: it lists the return fields, notes no auth, and explains the filtering purpose. It could mention behavior with no filters (e.g., returns all sessions) but that is minor given the openWorldHint and schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 seven parameters. The description adds a slight prioritization by calling out 'filter by year, country or session_name', but this doesn't add substantial new meaning. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses a specific verb+resource: lists F1 sessions (Practice/Qualifying/Sprint/Race) and identifies itself as the 'fixtures feed'. It clearly distinguishes from sibling tools like openf1_meetings and openf1_session_result by explaining its role in the workflow (find a session_key).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: it's the fixtures feed for finding session_keys by year, country, or session_name. It implies when to use (need schedule) vs. when to use other tools (need results), but doesn't explicitly name alternative tools or exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_enumsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it as read-only and idempotent. The description adds value by showing a sample return structure (countries array) and noting that no authentication is required, which helps the agent understand what to expect without exceeding 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, front-loaded with purpose, and neatly structured with a sample return and auth note. Every sentence contributes useful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, so the description's sample return structure is helpful. However, it only shows one enum type and uses '...' to suggest more, leaving some ambiguity about the full set of enums and their structures. Given the simplicity of the tool, this is reasonably complete but not exhaustive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters, so the description does not need to explain them. The zero-parameter baseline of 4 applies, and the description correctly omits any parameter details since there are none.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies this as a reference tool for enums used across the API, which distinguishes it from other Pinnacle tools that focus on sports, leagues, or matchups. The phrase 'Reference enums' is specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is for getting reference data, but it does not explicitly state when to use it over other tools or provide exclusions. Since it's a self-contained enum lookup with no parameters, usage is obvious, but no explicit guidance is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_matchup_marketsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent, so the description adds value by clarifying the return format (array of objects with fields), price type (American odds), and stating no auth needed. This goes beyond the annotations with useful behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences: purpose, return shape, auth requirement. It is front-loaded with the primary action and contains no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool with good annotations, the description includes the essential return structure and auth requirement. It does not elaborate on what 'related markets' includes, but the schema supplies the prerequisite, making the description reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the single required parameter matchupId, including the 'hasMarkets=true' prerequisite. The description adds no extra parameter semantics; it only mentions matchupId as part of the return shape, so the schema carries the full burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns all straight (non-parlay) markets with American-odds prices for a matchup and its related markets. The verb 'returns' and resource 'markets' are specific, and the phrase 'non-parlay' distinguishes it from sibling tools like parlay markets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for straight markets via 'non-parlay' and includes context about the scope (one matchup + related markets), but doesn't explicitly name alternatives or state when-not-to-use. The exclusion of parlays is a strong hint, but not a fully explicit guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_matchup_parlay_marketsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral details: the exact return structure (array of market objects with key fields), that prices are American odds, and that no authentication is required. This goes beyond the annotations and helps the agent understand expected output.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences plus a compact return-format preview. It front-loads the core purpose, and every sentence provides useful information (scope, return shape, odds format, auth). No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description includes the return structure, odds format, and auth requirement, which are the key details an agent needs. It doesn't explain 'related markets' in depth, but for a single-parameter read-only tool, this is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage for matchupId, including its type, requirement, and the note that the matchup must have hasMarkets=true. The description adds no additional parameter meaning, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning parlay (same-game multi) markets and prices for a specific matchup and its related markets, distinguishing it from sibling tools like pinnacle_matchup_markets. The verb 'Returns' is specific and the resource (matchup's parlay markets) is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for parlay markets specifically, giving clear context for when to use it (when parlay/same-game multi data is needed). However, it does not explicitly state when not to use it or name alternative tools like pinnacle_matchup_markets for non-parlay markets, so it falls short of full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_match_statsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context: return structure (array of 2 objects with side/teamId/stats), the scale of data (~200 metrics), and that no auth is needed. It does not repeat annotation information, complying with the guideline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded: a concise summary, then return format, then auth. It uses bullet-like lines and an example of the return shape without unnecessary prose. Every sentence provides useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description compensates by showing the return structure and example fields. It covers the essential aspects: what it returns, the shape, scale, and auth. It does not mention error cases or pagination, but these are not critical for a read-only stats endpoint with a single required parameter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the single 'id' parameter with a clear description ('Match id. Required — part of the URL path.'). The tool description itself adds no extra parameter semantics beyond what the schema already states, so it meets the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb and resource: 'Full team match stats' with ~200 Opta metrics. It distinguishes from sibling tools like pl_match and pl_match_events by focusing on team-level granular stats and providing a return structure example.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context—if you need comprehensive team-level stats for a match, use this tool. It clearly indicates what data it returns (possession, shots, xG, etc.), but it does not explicitly name alternatives or state when not to use it. That prevents a higher score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_matchweek_matchesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context beyond these: 'Auth: none needed' and the concrete return shape including pagination and data fields. This gives the agent a clear expectation of the response without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, consisting of three short lines. It is front-loaded with the main purpose, immediately followed by the return type and auth requirement. Every sentence earns its place, with no redundant or vague wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool, the description is nearly complete: it provides the return shape, auth requirement, and relationship to a sibling. It lacks explicit details on pagination mechanics (e.g., how to page through results beyond the limit parameter), but the presence of a pagination field in the return and the limit parameter in the schema partially cover this. Overall, it is adequate with only minor gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all four parameters (mw, cid, sid, limit) already described in the input schema. The description does not add additional parameter details beyond mentioning matchweek, but it does imply that cid, sid, and mw are path-based parameters via 'v1 path alternative'. This is minimal added value, so it stays at the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as fetching 'Matches for one matchweek' and explicitly positions it as a 'v1 path alternative to pl_matches?matchweek=', distinguishing it from sibling tools. The verb and resource scoping are specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by stating this is an alternative to pl_matches?matchweek=, implying when this path-based route might be preferred. It does not explicitly state when not to use it or mention other alternatives, but the context is sufficient for an agent to make a reasonable choice.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_player_comp_statsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, setting a safe-read baseline. The description adds value by specifying the return structure (player and stats with Opta metrics) and explicitly stating 'Auth: none needed.' This goes beyond annotations by giving insight into the response shape, though it does not cover potential rate limits or edge cases.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: a one-sentence summary of purpose, followed by return format and auth info. Every line contributes meaning without redundancy or extraneous detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two well-documented parameters and strong annotations, the description is sufficiently complete. It provides a sample return structure, clarifies auth requirements, and states the aggregation scope. No output schema exists, but the informal return signature helps the agent understand the tool's output.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage, with each parameter (cid, pid) described as an integer and part of the URL path. The description itself does not add much parameter-level detail beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'A player's career stats aggregated across the competition (all seasons).' This specifies a distinct verb+resource (retrieve career stats) and scope, differentiating it from sibling tools like pl_player_season_stats or pl_player_leaderboard.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: when aggregated career stats across all seasons for a player in a competition are needed. It does not explicitly name alternatives or exclusions, but the 'all seasons' aggregation and the need for cid/pid make the intended use unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_players_by_idA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds that auth is not needed, which is useful, and shows the exact return shape. But it doesn't disclose behavior like whether missing IDs are silently ignored, error handling, or rate limits. Given annotations cover the safety profile, a 3 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two sentences with a return format and auth note. Every line earns its place. The 'Returns:' line is front-loaded with the most critical information, followed by the simple auth disclaimer.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given this is a simple lookup tool with one parameter, no output schema, and strong annotations (readOnly, idempotent), the description covers the core semantics well. It could mention what happens with invalid/unknown IDs or the max batch size, but for a simple read-only batch lookup, the description is near-complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage: the only param 'id' is described as 'Player id(s)' with an example '[200785, 223094]'. The description adds context that this is a batch lookup and the expected return format. The schema is already quite clear, so the description adds marginal but useful value above the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Batch player lookup by a list of ids' with the specific use case 'hydrates lineups/squads', which distinguishes it from single-player lookups like pl_player or pl_player_basic. The return format is explicitly shown as a top-level array of objects with id, name, firstName, lastName.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when you need to look up multiple players by IDs at once, especially to hydrate lineups/squads. However, it doesn't explicitly state when NOT to use it or mention alternatives like the single-player lookup tools (pl_player, pl_player_basic) for individual lookups.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_teamsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the read-only nature is known. The description adds useful behavioral context: pagination, the exact return shape, and that no auth is needed. It does not contradict any annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the first line defines the resource and its contents, followed by a concise return-type sketch, a concrete example, and a clear auth note. Every sentence carries useful information with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple list operation, the description is complete enough: it specifies pagination, return fields, auth requirements, and a practical example. The absence of an output schema is mitigated by the inline return shape, and the input schema fully documents limit and next_cursor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value by giving a concrete example ({"cid": 8}) that maps to Premier League and by stating the return payload structure, which helps disambiguate how cid is used. This lifts it above the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns all teams that have played a competition, with specific fields listed ('seasons[], stadium, name, shortName, abbr, id'). It is unambiguous as a list operation and the example ties it to Premier League teams via cid. However, it does not explicitly differentiate itself from sibling tools like pl_team, pl_season_teams, or pl_teams_by_id.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use this to fetch all teams for a given competition, demonstrated with the Premier League example (cid: 8). It does not state exclusions or explicitly mention alternative tools, but the 'all teams' framing makes the intended use reasonably clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_event_searchA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description only adds 'Auth: none needed' and the return format. These are useful but limited; it does not disclose pagination behavior, result limits, or error handling. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the main action. It includes only essential extras: return format, a concrete example, and auth note. Every sentence earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with 4 optional parameters, the description covers the main purpose, includes a return example, and specifies auth. It lacks an example using eventClassIds and doesn't address edge cases like empty results, but the schema and example provide enough context for typical use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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's example (competitionKey 7523, numberOfSportEvents 50, includeHistoricStats true) adds concrete usage context, clarifying how parameters combine and emphasizing the 'class / competition' filtering concept beyond the schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Search sport events by class / competition, optionally with historic head-to-head stats' with a specific verb and resource. It distinguishes itself from sibling PointsBet event tools like pointsbet_event and pointsbet_competition_events by emphasizing search across classes/competitions and optional historic stats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool—searching sport events by class/competition, especially when historic stats are desired, as shown in the AFL example. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_inplay_streamingA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint true, and the description complements these by adding that no auth is needed and by detailing the exact return format. It also notes the data is grouped by sport. This provides useful behavioral context beyond the annotations, though it does not mention rate limits or other edge behaviors.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: one purpose sentence, a return structure, and an auth note. Every element is necessary and clearly formatted. It avoids verbosity and repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters, no output schema), the description provides enough information: the purpose and the return structure. It could have explained what 'visionData' contains (e.g., the actual stream URLs) but this is a minor gap. The description is otherwise complete for an agent to understand and invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is nothing to document. The description correctly omits parameter details, and the schema has full coverage (100%). The baseline for zero parameters is 4, and the description does not need to add anything else.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns in-play events with live video streams, grouped by sport, which is specific and distinguishes it from sibling tools like pointsbet_sports_inplay (which likely lists all in-play events without the video requirement). The return structure is also explicitly detailed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case: if you need in-play events that have live video streams, this is the tool. However, it does not explicitly name alternatives or state when not to use it. The context signals show many sibling tools, but no direct comparison is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_racing_raceA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and open-world hints. The description adds that results and dividends are returned only after the race has run, and provides an explicit return structure, which is valuable conditional behavior context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two clear sentences plus a compact return example. It front-loads the purpose and provides a structured output shape without unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one parameter and no output schema, the description provides a clear return structure and conditional results behavior. It is adequate, though it does not elaborate on field meanings or error cases, which are not critical for this simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The sole parameter raceId is fully described in the input schema, including its source and that it is a URL path parameter. The tool description adds no additional parameter-specific meaning, but schema coverage is 100%, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it provides a full racecard for one race, including runners, prices, track/conditions, and results/dividends once run. This specific scope distinguishes it from sibling tools like meeting-level or race-list tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly implies use when detailed racecard data for a specific race is needed, and explicitly mentions 'Auth: none needed.' However, it does not explicitly name alternative tools or provide when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• polymarket_tagsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context: the return format (top-level array with fields) and that no auth is needed. It does not contradict annotations and adds meaningful detail beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, with each sentence earning its place: purpose, return format, and auth. It is front-loaded and free of filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple catalogue tool with good annotations and a sample return layout, this is nearly complete. It could explicitly mention pagination via limit/offset, but the schema covers that. It might also clarify that the list is static or changes externally, but openWorldHint hints at that without needing explanation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers both parameters (limit, offset) with descriptions, so schema coverage is 100%. The description does not add anything about parameter behavior beyond what the schema states, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this is a tag catalogue with concrete examples (Sports, Politics, Crypto, NBA) and explicitly notes that tag ids feed the tag_id filters. This distinguishes it from sibling polymorphic tools that consume tags.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool should be used to obtain valid tag IDs for filtering other queries, but it does not explicitly name alternative tools or state when not to use it. The context is clear enough for an agent to infer the primary use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• racingandsports_race_oddsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds extra context by stating 'Auth: none needed' and that the return shape is served to the form-guide XHR, which goes beyond the structured fields. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded with the core purpose. The separation of token dependency, return shape, and auth into distinct lines makes it easy to scan. Every sentence provides useful information with no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read-only tool with good annotations and schema descriptions, this description is nearly complete. It covers purpose, parameter source, return shape, and auth. It does not explicitly name the form-guide tool (e.g., racingandsports_todays_racing) or discuss openWorldHint implications, but those are not essential for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and both parameters are well-documented in the schema (token as per-race access token, raceId as race id). The description reinforces this by repeating that both come from the form-guide view, but it does not add new semantic details beyond the schema, so a baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns bookmaker odds for one race, with the scope explicitly limited to a single race via a per-race token. It distinguishes itself from sibling tools like racingandsports_todays_racing by emphasizing the per-race granularity and the token requirement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explains the prerequisite (per-race token issued by the form-guide page) and explicitly states that raceId and token come from the form-guide view, giving clear context on when to use it. It does not name alternative tools or state when not to use it, but the source dependency is clear and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sleeper_draft_picksA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds valuable behavioral context beyond the annotations: it lists the exact return fields, notes that metadata carries player names (eliminating the need for a large player file), and explicitly states auth is not needed. This is more than what annotations alone provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: purpose, return structure, example, and auth. Every line adds distinct value with no redundancy. It is front-loaded with the core purpose and avoids unnecessary detail, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool, the description covers the essentials: what it returns, the input needed, and that no auth is required. With no output schema, the explicit return structure is helpful. It doesn't mention error scenarios or how to obtain draft_id, but those are minor gaps; the description is largely complete for its complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description covers draft_id fully (required, part of URL path), so baseline is 3. The description adds a concrete example value and clarifies that metadata carries player names, but this is more about return behavior than parameter semantics. The added value over the schema is marginal.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: it returns every pick in a draft in order, with player and drafter info. This distinguishes it from sibling tools like sleeper_traded_picks (which covers traded picks) and sleeper_draft (draft details), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use this to get all picks in a specific draft. It includes a concrete example of the required draft_id, showing how to invoke it. However, it does not explicitly mention when not to use it or point to alternatives like sleeper_traded_picks, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sleeper_stateA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds value by disclosing the exact return structure (list of fields) and stating 'Auth: none needed,' which is useful context beyond annotations. No contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: a one-sentence overview, a usage tip, a return-field list, an example, and an auth note. Every element earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description fully documents the return fields and provides an example. It also covers auth and usage context. The only minor gap is that the description says 'NFL state' while the parameter allows other sports, leaving slight ambiguity about non-NFL usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the single 'sport' parameter with an enum and a note about NFL being the live one. The description adds an example but no further parameter semantics. Since schema coverage is 100%, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: retrieving current NFL state including season, week, and scoring status. It also provides a specific usage directive ('Call this to resolve 'this week' instead of guessing'), which distinguishes it from sibling tools that focus on user/league data. The example further grounds the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says when to use the tool (to resolve 'this week') and frames it as a substitute for guessing. It does not mention alternatives or exclusions, but the guidance is clear and sufficient for a simple state-retrieval tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportmonks_typesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, open-world, and idempotent behavior. The description adds essential context beyond this: the expected return shape, a caveat that the shape is from vendor docs and unverified, the auth requirement ('needs your own key in SPORTMONKS_TOKEN'), and a pagination example. These disclosures are valuable for setting agent expectations about accuracy and invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately long but well-structured, with a clear lead sentence, a return-shape block, a cautionary note, an example, and an auth instruction. Each section serves a distinct purpose (purpose, output, reliability, usage, credentials) and is front-loaded with the core purpose. No extraneous content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description explicitly details the return structure ({data:[...], pagination}) with field names and examples. It explains why the tool is needed, provides usage context via the example, and includes a crucial caveat about data unreliability. For a simple 2-parameter lookup tool, this is highly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes both parameters ('Page number.' and 'Page size.') with 100% coverage. The description adds only a minor example using per_page=50, which does not significantly enhance understanding beyond the schema. Thus the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'resolves the numeric type_ids that appear all over events, statistics and standings details.' It uses a specific verb ('resolves') and identifies the resource ('type catalogue'), distinguishing it from sibling sportmonks tools that handle fixtures, teams, players, or standings directly. The inclusion of example names ('Goal', 'Yellow Card', 'Shots Total') further clarifies its role.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: 'Without this, a fixture's `events` and a player's `statistics.details` are unreadable — they are numbers.' This tells the agent to use this tool to decode numeric type IDs in specific data structures. It does not explicitly mention alternatives or when-not-to-use, but the context is sufficient for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_event_resultsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that auth is not needed, which is useful context beyond the readOnlyHint annotation. It also specifies the exact return structure (event with finalScore, markets with winningSelections), giving the agent a clear picture of what to expect. There is no mention of error handling for unfinished events, but annotations already cover safety, and the description adds meaningful detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three compact sections: a one-sentence purpose, a return type sketch, and an auth note. It is front-loaded with the most important information and contains no filler. Every sentence contributes.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 appropriately includes a return shape for both the event and markets, fulfilling the need to explain output. It also states auth requirements, which are useful for invocation decisions. However, it does not specify behavior for invalid IDs or whether markets are always present, so it is slightly short of a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully documents the single eventId parameter, including that it is required and part of the URL path. The description does not add additional parameter-level semantics beyond that, but with 100% schema coverage, the baseline of 3 applies. The mention of eventId in the return structure is incidental and does not explain the parameter further.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Results for a finished sport event (final score + settled markets)', which clearly specifies the verb (returns results), resource (sport event), and scope (finished events, final score, markets). This distinguishes it from sibling tools like sportsbet_event_status and sportsbet_event_markets, which likely target different aspects.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'finished sport event' provides clear context that this tool is for retrieving results after an event concludes. It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for an agent to choose this for completed events. No exclusions are stated, so per the rubric this aligns with 'clear context, no exclusions'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_graphql_callA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the operational safety is covered. The description adds valuable context: 'Hashes are managed server-side; a PERSISTED_QUERY_NOT_FOUND error means the bundle drifted' and 'Auth: none needed.' 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, starting with the action and endpoint, then addressing error behavior, discovery resource, return type, and auth. Each sentence carries distinct information with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description's 'Returns: (JSON object)' is minimal but acceptable for a generic GraphQL operation whose response shape varies by operation. It covers operation discovery, error semantics, and auth requirements, but it does not explicitly note that the expected response structure is also documented in the catalogue resource, which is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions already cover 100% of parameters, including guidance to consult the catalogue resource for valid names and variable keys. The description adds the specific URI 'sportsbet://graphql/operations' for obtaining the operation list and variable signatures, providing a direct discovery mechanism beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Call any of Sportsbet's persisted GraphQL operations against www.sportsbet.com.au/apigw/sportsbook/graph by name + variables.' This clearly distinguishes it from sibling generic-call tools (e.g., entain_graphql_call) by specifying the Sportsbet provider and endpoint.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It implies usage by directing the agent to 'Read sportsbet://graphql/operations for the op list + variable signatures,' which is a prerequisite step. However, it does not explicitly state when to prefer this generic GraphQL call over dedicated Sportsbet tools (e.g., sportsbet_event_markets) or provide exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_page_contentA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, establishing the safety profile. The description adds behavioral context beyond annotations by specifying the return format and that no authentication is needed. This is useful additional transparency without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: three short lines covering purpose, return shape, and auth. It is front-loaded with the primary purpose and every sentence adds value. No filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only content tool, the description covers the essential aspects: what it returns (modules structure) and that no auth is needed. The lack of an output schema is partially compensated by the inline return example. It could go deeper on item structure, but the minimal description is adequate for a straightforward content endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters 'tab' (with enum), 'loggedIn', and 'popularsrms' are fully documented in the schema. The description itself adds no parameter-specific meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides 'Homepage tab content (sports or racing landing modules)' – a specific resource with a clear scope. It distinguishes itself from the many sportsbet sibling tools by focusing on homepage tab modules, not events, markets, or racecards. The return shape is also described, further clarifying its purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: this is for homepage tab content for sports or racing. It also notes 'Auth: none needed,' which is useful guidance. However, it does not mention alternatives or when not to use this tool, which would be helpful given the large sibling set, but the context is strong enough to infer appropriate usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_racing_resulted_eventsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the return shape, states authentication is not needed, and indicates the operation is for resulted races. This is useful context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with purpose, includes a concise return structure and auth note, and has no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  It includes the return structure, auth requirement, and sibling coverage, which is sufficient for a simple read-only endpoint. It does not mention edge cases like empty results or error behavior, but these are not critical for this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the description merely restates the three identifiers (competitionId, classId, date) without adding extra meaning. The schema itself already documents date format and competitionId's role in the URL path.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Resulted races (placings + dividends) for a racing competition + class + date.' It clearly lists the return structure and mentions it can answer pointsbet_racing_race and tab_racing_race, which distinguishes it from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides context that this returns resulted races with placings/dividends and explicitly notes that it can serve as an answer for pointsbet_racing_race and tab_racing_race. However, it does not give explicit when-not-to-use or alternative instructions for other racing tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_track_reportA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by stating 'Auth: none needed' and explicitly detailing the return structure, which is not covered by annotations. No contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise lines: purpose, return structure, and auth. No fluff, front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description provides return format and auth, covering the absence of an output schema. It is slightly incomplete regarding behavior when multiple meetings exist on the same date, but the optional trackName parameter implies disambiguation. Overall, adequate for a simple read tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% as all three parameters have descriptions in the input schema. The description's 'Track report... on a date' aligns with the required eventDate parameter, but adds no additional semantic detail beyond the schema's parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies a track report with specific data fields (going, rail, weather) for a racing meeting on a date. It distinguishes itself from sibling racing tools by focusing on track conditions and returning a structured track object.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context: use this for track condition information for a meeting on a given date. It does not explicitly name alternatives or state when-not-to-use, but the purpose is specific enough to infer appropriate usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_upcoming_eventsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, open-world behavior. The description adds useful context: no auth required and the exact return payload shape. This goes beyond the structured annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, using three short sentences to cover purpose, return shape, and authentication. No filler or repetition, and the key information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple listing tool with strong annotations and full schema coverage, the description is nearly complete. It includes the return shape and auth requirement, though it omits details like ordering or pagination behavior, which are partially covered by the maxEvents parameter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes both parameters (maxEvents and includePrimaryMarket) with 100% coverage. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it lists upcoming sport events across all codes, identifying it as the homepage upcoming feed. This specific scope distinguishes it from sibling tools like event-specific or competition-specific endpoints.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It conveys when to use it (to get a broad, cross-code upcoming events feed) and notes it's the homepage feed, which implies it's a general entry point. It does not explicitly name alternatives or exclusions, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsdataio_nfl_scoresA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety is covered. The description adds valuable behavioral context: the return shape is from vendor docs and unverified, the meaning of SeasonType values, and the need to inspect actual payload. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized and concise despite including detailed return shape, caveat, example, and auth info. Each section earns its place, and the information is front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read-only tool, the description provides everything needed: inputs, output shape, auth, and a caveat about unverified data. It does not explicitly differentiate from alternative NFL score tools, but the overall coverage is strong.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully described in the schema (100% coverage), but the description adds extra meaning by explaining the season type suffix (e.g., '2023POST') and clarifying that a bare year means regular season. The example also reinforces parameter usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb ('returns') and resource ('NFL scores for one season and week'), with a specific scope that differentiates it from sibling NFL tools like sportsdataio_nfl_teams. The explicit return shape clarifies the exact data provided.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (to get scores for a specified season and week) via the example, but it does not explicitly contrast with alternatives or mention when not to use it. No exclusion criteria or alternative tool recommendations are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsdataio_nfl_teamsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, idempotentHint), the description adds valuable context: the return shape is unverified from vendor docs and should be treated as approximate, and authentication requires a provider key. This honesty about uncertainty and auth requirements exceeds the baseline annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and information-dense. Every sentence adds value: the summary line, return shape example, verification caveat, usage example, and auth note. No unnecessary fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description provides a detailed return shape sample and auth requirements. It acknowledges the shape is unverified, which is honest but also means the agent must inspect actual payloads. For a zero-parameter static data tool, this is sufficient and transparent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters, so the baseline is 4. The description compensates by documenting the return shape with specific field names and PascalCase convention, adding semantic meaning even though no parameters need explanation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the resource ('NFL franchises') and the specific data included (conference, division, stadium, coach). The example 'Every NFL team' reinforces the intent. This distinguishes it from sibling NFL tools like sportsdataio_nfl_scores.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for retrieving NFL team metadata but does not explicitly state when to use it versus alternative tools or provide exclusions. The 'Example: Every NFL team' gives a use case but no guidance on alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• squiggle_gamesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, idempotent, and open-world behavior. The description adds useful behavioral details: the exact return structure, the note that no authentication is needed, and the data fields included. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-line summary, a clear return type snippet, an example, and an authentication note. Every section earns its place with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, and the description includes return fields, an example, and auth requirements, which compensates partially for the lack of an output schema. The schema handles parameter details, so the overall context is adequate, though it does not mention data freshness or size limits.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with descriptions for all six parameters, so the baseline is 3. The description adds an example with q, year, and round, but it does not add new meaning beyond the schema's already detailed parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns AFL fixture and result data with scores, venue, and completion state. This specific verb+resource combination distinguishes it from sibling tools like squiggle_teams, squiggle_standings, and squiggle_ladder.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on what the tool does and shows an example with parameters, making it obvious when to use it. It does not explicitly name alternatives or exclusions, but the scope is evident from the summary and the sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• supercoach_leaguesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds 'Auth: none needed', notes these are 'public/featured' leagues, and spells out the return shape, going beyond the annotation baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and information-dense: purpose, return shape, example, and auth in a minimal number of sentences. Every line earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, usage, return fields, example, and auth; combined with rich schema and annotations, it is sufficient for an agent to invoke this tool. Minor omission: does not mention whether the list is exhaustive or if there are any limits, but the openWorldHint covers extensibility.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers all parameters with detailed descriptions (e.g., mode, year calendar nuance, sport options), and the description does not add additional parameter semantics beyond the schema. Baseline 3 applies due to high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns 'public/featured leagues for one sport+season+mode' and enumerates the fields returned, which distinguishes it from sibling tools like supercoach_players or supercoach_teams. The phrase 'Useful to discover competition_ids and the league types on offer' further anchors its specific purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Gives a clear use case ('Useful to discover competition_ids and the league types on offer') but does not explicitly discuss alternatives or exclusions. It implies when to use but doesn't compare to other SuperCoach tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• supercoach_settingsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the tool as read-only, idempotent, and open-world. The description adds useful behavioral context beyond annotations: 'Tiny (~15 KB)', the exact response shape, an example call, and 'Auth: none needed.' It does not mention rate limits or failure modes, but for a small read-only settings endpoint, the added context is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is information-dense and front-loaded with the core purpose, then moves to usage, return structure, and example. However, there is some redundancy: the 'Returns:' section repeats fields already listed in the opening sentence. Each sentence contributes value, but the duplication slightly lowers efficiency.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple, read-only, and returns a small structured payload. The description covers the purpose, key fields, usage workflow (call before supercoach_players), expected size, authentication, and provides a concrete example. No output schema exists, but the description explicitly lists the return structure, making the tool fully self-contained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the parameter descriptions in the input schema already fully explain sport, year, mode, and min. The description adds an example ('{"sport": "afl", "year": 2026}') and a note about round selection, but does not materially enrich the parameter semantics 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Competition state for one game+season' with a specific list of returned fields (current_round, next_round, lockout info, etc.). It distinguishes itself from sibling tools by explicitly saying 'Call this FIRST to learn which round to pass to supercoach_players', making its role in the workflow unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use guidance: 'Call this FIRST to learn which round to pass to supercoach_players.' This provides clear context and a concrete predecessor relationship. It does not mention explicit when-not-to-use or alternatives beyond the single downstream tool, so it falls just short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_competitionA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, establishing safety. The description adds meaningful behavioral details: it works without authentication, and providing TAB_CLIENT_ID/TAB_CLIENT_SECRET unlocks more data. It also discusses optional top markets in the return. No contradiction with annotations; the added auth context pushes beyond the baseline.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: purpose, return structure, example, and auth note are in three sentences plus an example block. Every sentence adds new information, and the most critical info (what it does) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a return structure and clarifies optional fields. It also mentions authentication requirements. It does not explain betOptions, sameGame, or jurisdiction semantics, but the schema covers params. For a read-only tool with good annotations, this is near complete; a small gap is the lack of explanation about the 'numTopMarkets' default and jurisdiction's impact.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds value through a concrete example mapping 'sport' and 'competition' to actual values, and implies numTopMarkets via 'optionally top markets'. This clarifies usage beyond the schema's generic descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Competition page: its matches, bet options and (optionally) top markets', which clearly specifies the resource (competition) and what it returns. It also includes a concrete example ('AFL Football' / 'AFL') and a return structure, distinguishing it from sibling tools like tab_sport or tab_match.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for competition-level data but does not explicitly state when to use this tool versus alternatives. There is no 'use this instead of X' guidance, and the example only illustrates parameter values without contextualizing the choice. The context signal of many sibling tools makes this absence notable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_featured_eventsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already show readOnly, openWorld, and idempotent. The description adds useful context beyond that by specifying the return shape, an example, and auth behavior ('works without a key; TAB_CLIENT_ID ... unlocks more'). It doesn't fully explain what 'unlocks more' entails, so not a perfect score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a one-line purpose, a return shape block, an example, and an auth note. It is concise and front-loaded, although the example line ('Featured carousel for NSW') is slightly redundant with the input example.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that there is no output schema, the description compensates by hacking a clear return-shape example. For a simple read-only tool with one optional param, the description — reinforced by annotations — is fully sufficient for an agent to understand and invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There is one optional parameter with complete schema coverage ('jurisdiction' described as 'State jurisdiction'). The description reinforces the example with 'NSW', but adds no further semantic detail about the parameter beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool returns 'Editorially featured events across racing + sports for the homepage carousel', which clearly identifies the resource and the content. The phrase 'editorially featured' distinguishes it from personalized or algorithmic tools in the long sibling list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly places the tool in a usage context ('for the homepage carousel') and provides an example call with jurisdiction. However, it does not discuss when to avoid it or point to a direct alternative among the siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_racing_meetingsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations (readOnly, openWorld, idempotent) are consistent with the description, which also adds authentication notes (works without a key, unlocks more with credentials). No side effects are mentioned, but the annotations cover the safety profile adequately.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is succinct and well-structured: a one-sentence purpose, a return shape example, a usage example, and authentication info. No unnecessary detail or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description includes an example and authentication note, and the schema covers parameters. It lacks an explicit mention of default values (e.g., jurisdiction defaults to NSW) but that is present in the schema. Overall, it is complete enough for typical use, though it could benefit from a note on optional parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for all four parameters (date, returnPromo, jurisdiction, returnOffers). The tool description does not add further clarification beyond the schema, but the schema descriptions are terse (e.g., 'Inline promotions'). The description could have elaborated on the effect of these optional parameters, but it does not, so it relies solely on the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that it returns all race meetings for a given date, including their races. It distinguishes this tool from others by specifying the scope (meetings with embedded races) and the required date parameter.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an example usage and mentions authentication requirements, but it does not explicitly contrast with alternative tools (e.g., tab_racing_meeting_races). However, the example and the focus on 'for a date' make the intended use clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_racing_runner_formA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already include readOnlyHint, so the description adds value by specifying auth requirements ('works without a key; TAB_CLIENT_ID or TAB_CLIENT_SECRET unlocks more if set') and return structure. No contradictions with annotations. Could clarify what 'unlocks more' entails, but overall transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with purpose, and uses two clear paragraphs. Every sentence adds value: purpose, return shape, and auth. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given complexity (6 params, no output schema), the description adequately covers purpose, return structure, and auth. It does not mention potential limits or error cases, but for a read-only, idempotent tool, this is sufficient. The '...' in the return structure indicates additional fields but doesn't hurt completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the description does not need to repeat parameter meanings. It adds a return structure that echoes runnerName/runnerNumber, but no extra parameter semantics beyond what the schema already provides. Baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this tool provides 'DETAILED per-runner form: full past-start history with positions, margins, distances and dates.' It identifies a specific resource (per-runner form) and distinguishes from sibling tools like tab_racing_race_form or pointsbet_racing_form by emphasizing per-runner granularity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it (when you need detailed past starts for a single runner) but does not explicitly exclude alternatives or state when not to use it. It provides clear context but lacks explicit guidance on alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_sportsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable context beyond annotations by specifying the exact return structure and the auth behavior, including that no key is required and that setting TAB_CLIENT_ID or TAB_CLIENT_SECRET unlocks more. This is useful behavioral transparency, though the "unlocks more" claim is somewhat vague.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: it states the core purpose, gives the return shape, and mentions auth requirements in three short sentences. Every sentence adds useful information, and there is no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Since there is no output schema, the description compensates by including the return shape and field names. It also covers auth requirements, which is useful for an agent deciding whether credentials are needed. The description is adequate for a simple list-style tool, though the optional jurisdiction parameter and its effect on results are only clarified in the schema rather than in the description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents the single optional jurisdiction parameter with 100% coverage, including its default value and meaning as "State jurisdiction." The description does not add any additional parameter-level semantics, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning all sports offered, explicitly framing it as the "HATEOAS root for the sports tree." This distinguishes it from sibling tools like tab_sport or tab_competition, which target specific levels of the hierarchy. The inline return shape further confirms the resource and its purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase "HATEOAS root for the sports tree" gives clear context that this is the entry point for navigating sports, and "each linking to its competitions" shows how it connects to downstream tools. It does not explicitly name alternatives or state when not to use it, but the root concept is strong enough for an agent to infer appropriate use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_tournamentA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnly, openWorld, and idempotent behavior. The description adds extra context about authentication ('works without a key' and unlocking more with credentials), and it specifies the return structure, which goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and efficient: a purpose statement, return shape, a concrete example, and an auth note. Every sentence adds value, with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description provides the return structure, an example, auth details, and usage context. It is sufficiently complete for an agent to invoke the tool correctly, though it could benefit from additional notes on pagination or market details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All five parameters are fully described in the schema (100% coverage), so baseline is 3. The description adds an example with concrete values but does not introduce significant new meaning beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that this tool returns a tournament page nested inside a competition, including matches and top markets. It provides a concrete example (Wimbledon) and distinguishes itself from competition-level tools by noting that competitions with an empty matches list point to this tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit guidance on when to use this tool: 'Competitions whose page shows matches:[] list their events here.' It also provides an example query and mentions auth requirements, but does not explicitly name alternative sibling tools for contrast.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_tweetsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, and the description aligns with those by calling it a 'lookup'. The description adds genuinely useful behavioral context beyond the annotations: the 100-ID limit, the auth requirement (X_BEARER_TOKEN), and the return object shape. This is valuable supplemental information without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: one purpose sentence, a one-line return shape, and a one-line auth note. It is front-loaded and every sentence carries meaningful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that the schema covers all parameters and there is no output schema, the description compensates with a clear return structure and auth requirement. It does not mention rate limits or error handling, but for a simple batch lookup with strong annotation coverage, the provided context is sufficient for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all 4 parameters, so the description does not need to repeat parameter docs. It adds the 'up to 100' limit and engagement metrics mention, but those are also present in the schema (ids description and tweet_fields default). No additional meaning is provided beyond the schema, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with a specific verb+resource ('Batch post lookup by ids') and includes key scope ('up to 100') and a differentiator ('with engagement metrics'). It clearly distinguishes this batch endpoint from the singular 'twitter_tweet' sibling by emphasizing batch behavior and metrics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Batch post lookup by ids' clearly signals this is the tool to use when fetching multiple posts by their IDs. It does not explicitly name alternatives or exclusions, but the batch-ids scope is clear from context, and the sibling tool list shows a singular variant that would serve single-post needs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_usageA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, idempotent, and openWorld hints. The description adds meaningful context beyond that, including the required auth header (X_BEARER_TOKEN) and the exact return shape, and frames the tool as a pre-flight quota check.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a purpose/action line, a return shape line, and an auth line. Every sentence carries useful information with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description's explicit return shape is essential and provided. Auth requirements and usage context are also included. Minor edge cases like behavior when the cap is exceeded are not discussed, but complexity is low and annotations cover safety aspects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and both parameters (days, usage_fields) already have descriptions, so the description doesn't need to repeat them. The Returns line gives useful field-level context, but no additional parameter-specific semantics are needed beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it retrieves the project's post-read usage against its monthly cap, and the imperative 'check before burning quota' reinforces the tool's purpose. This is distinct from sibling Twitter data tools like twitter_tweets or twitter_search_recent, which fetch content rather than usage metrics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  'Check before burning quota' provides direct guidance on when to use the tool: before consuming API quota. It does not explicitly name alternatives or exclusions, but the tool's purpose naturally separates it from data-fetching siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_userA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, idempotent, and openWorld. Description adds the auth requirement and the exact return structure, both useful behavioral details not present in annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences deliver purpose, return shape, and auth context with no filler. The most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  As a simple single-account getter with no output schema, the description compensates with a concrete return shape and auth caveat. It lacks detail on how user_fields affects the response, but the schema already covers that parameter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and both parameters have descriptions. The description adds little beyond reiterating the numeric id and showing return fields that include public_metrics, which indirectly hints at user_fields usage but does not add new parameter-level detail.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description opens with 'One account by numeric user id', a specific verb/resource/scope. It distinguishes this from sibling tools like twitter_user_by_username and twitter_users, making the intended target clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Implies use when you have a numeric user id, and states the authentication requirement. It does not explicitly name alternatives (e.g., username lookup), but the sibling context and tool name provide sufficient situational guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_user_mentionsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds the auth requirement (X_BEARER_TOKEN) and the exact return structure, which are valuable behavioral details. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: one line for purpose, one for return format, one for auth. Every sentence adds value and it is front-loaded with the core purpose. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even without an output schema, the description provides the return structure and auth condition, making it self-contained. It could be more complete by explicitly mentioning pagination or contrast with user tweets, but for a retrieval tool this is quite comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: all five parameters have clear descriptions (e.g., 'Numeric user id. Required — part of the URL path.'). The description's 'mentioning an account' adds slight context for the id parameter, but the schema already carries the parameter semantics, resulting in the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Recent posts mentioning an account' uses a specific verb+resource and clearly states the return type. It distinguishes from sibling tools like twitter_user_tweets (posts by the user) and twitter_search_recent (general search). The inclusion of the return format reinforces the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you need posts that mention a specific account. It provides context (recent posts, mentions) but does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_users_by_usernamesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, signaling a safe read operation. The description adds useful context: batch size limit (up to 100), return shape, and authentication requirement (X_BEARER_TOKEN). It doesn't detail pagination or error behavior, but for a lookup tool with strong annotations, this is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three crisp sentences: what it does, what it returns, and auth requirement. No filler. Front-loaded with the core action. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with 2 params, no output schema, and good annotations. The description covers purpose, return shape, and auth. It lacks mention of error cases or rate limits, but for a read-only batch lookup, the provided info is largely sufficient. A small gap is not specifying the format of the returned data (e.g., 'data' field) more explicitly, but it's enough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters described in the schema. The description does not add parameter details beyond the schema, but the schema's own descriptions are clear (handle without @, up to 100; user fields as CSV). The description's return fields hint at what user_fields might include (name, username, public_metrics) but not extensively. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool does a batch profile lookup by handles with a max of 100. It specifies the resource (Twitter users) and the verb (lookup), and provides the return shape. Among siblings like twitter_user_by_username and twitter_search_recent, this is distinct as a batch handle lookup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you have handles and need batch profiles, use this. It doesn't explicitly mention when to use alternatives like twitter_user_by_username for single lookup, but the batch limit and return fields give clear context. No exclusions are stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• unibet_kambi_callA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint, idempotentHint, openWorldHint) already communicate the read-only, idempotent, open-world nature. The description adds valuable behavioral context: default parameters (lang/market/channel_id) are automatically carried, the caller supplies only variable path/query params, and no auth is needed. It also directs to the operation list. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: three meaningful sentences plus a terse return and auth note. It front-loads the core purpose, then covers key behavioral details. No wasted words; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's generic dispatch nature, the description covers the essential context: the operation catalogue source, default handling, and auth. With no output schema, it keeps return value description minimal but sufficient. It could be slightly more explicit that response shapes vary by operation, but overall it provides enough for an agent to use the tool correctly after consulting the listed operations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for operation, path_params, and query_params. The description adds meaning by stating that defaults are carried and gives examples of variable params (eventId, sport, groupId). It also tells where to find valid operation names, which complements the schema's note about the catalogue. This enriches the bare schema with practical usage context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Fetch a Unibet/Kambi sportsbook resource by operation name (market AU)'. It specifies the generic dispatcher nature (by operation name), the specific market (AU), and differentiates from sibling tools like unibet_kambi_live_stats and unibet_kambi_odds_ladder which are dedicated operations. The pointer to the operation catalogue further clarifies the resource scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides implied usage guidance: 'Read unibet://sport/operations for the operation list' suggests the initial step of selecting an operation. It also notes defaults are carried so caller supplies only variable params. However, it does not explicitly state when to use this tool versus the dedicated Unibet/Kambi sibling tools, nor any exclusions. This is useful but not fully explicit about alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• unibet_kambi_odds_ladderA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare the read-only, open-world, and idempotent nature. The description adds that no authentication is required and provides the return structure ({name, steps:[{odds, converted}]}), which is useful since no output schema exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, front-loaded with the purpose. It efficiently communicates the core definition, return format, and auth requirements without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only reference with no parameters and no output schema, the description covers the return format and data scope (fractional + decimal ladders). It lacks some detail on field meanings (e.g., 'converted'), but overall is sufficient for the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema already covers everything. The description does not need to add parameter semantics; baseline of 4 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a Kambi odds-ladder reference, explaining that it provides decimal-odds increments. It is specific to the odds-ladder concept and distinct from sibling tools like unibet_kambi_live_stats or unibet_kambi_call.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use for looking up odds increments or converting odds, but it does not explicitly state when to use it or mention alternatives. No exclusions or comparisons to sibling tools are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_league_playersA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish readOnly/openWorld/idempotent behavior; the description adds valuable operational context: a hard 25-per-page cap with pagination via 'start', an explicit auth requirement, and a prominent caveat that the documented response shape is unverified and should be inspected at runtime. This goes beyond the structured metadata without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The purpose is front-loaded in a punchy phrase, and the response-shape block, caveat, example, and auth note are each purposeful. While the return shape is lengthy, it compensates for the lack of an output schema and is clearly separated into labeled sections.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the schema fully documents parameters and annotations cover safety traits, the description supplies the remaining essential context: pagination behavior, auth setup, an approximate return shape, and an explicit warning about unverified vendor documentation. This is complete enough for an agent to invoke the tool correctly and inspect the payload sensibly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% parameter coverage, including enums, defaults, and per-parameter descriptions, so the description does not need to repeat those details. The description's example and pagination note add usage context but not new parameter-level meaning beyond the schema's existing explanations.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource ('player pool') and the distinguishing scope: availability filtering (free agents/waivers/all) for add/drop decisions. This separates it from sibling tools like yahoo_team_roster and yahoo_player_stats by emphasizing league-wide availability rather than roster or individual player stats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use it — as the 'add/drop shortlist' for fantasy availability — making the intended use obvious. However, it does not explicitly name alternatives or state when not to use this tool, so it stops slightly short of the top criterion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_league_teamsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already mark the tool as read-only and idempotent. The description adds important context by warning that the return shape is from vendor documentation and has not been verified against a live response, and it explains the authentication requirement via YAHOO_CLIENT_ID, YAHOO_CLIENT_SECRET, or YAHOO_REFRESH_TOKEN.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is structured with purpose, return shape, caveat, example, and auth. It is somewhat dense due to the inline nested JSON shape, and the 'SHAPE FROM VENDOR DOCS' note is repeated in the following paragraph, but every section earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a detailed approximate return payload, highlights operationally important fields, warns about reliability, gives an example invocation, and states the auth requirement. This is sufficient for an AI agent to invoke the tool reasonably and set expectations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully documents both parameters, so the baseline is 3. The description adds a concrete example leagueKey value ('449.l.12345'), reinforcing the league-key format beyond the schema's 'part of the URL path' explanation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Every team in the league with its manager' and clarifies the core use case: 'how you map team_key to a person.' It names the resource and the returned scope, distinguishing it from sibling tools like yahoo_team or yahoo_league_standings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool — when you need a league-wide team-to-manager mapping — and gives an example input. However, it does not explicitly describe when not to use it or mention alternative tools such as yahoo_team, yahoo_my_teams, or yahoo_league_standings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_my_gamesA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly and idempotent hints, so the safety profile is covered. The description adds valuable context: authentication requirements (YAHOO_CLIENT_ID, YAHOO_CLIENT_SECRET, or YAHOO_REFRESH_TOKEN) and an explicitly flagged caveat that the response shape is unverified vendor documentation and should be inspected before relying on field names.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose and usage guidance, followed by a detailed return shape and caveat. The 'Example: The user's games' line adds little value and could be removed, but overall the content is dense and not redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple zero-required-parameter read tool with no output schema, the description is unusually complete: it explains the return shape, warns that the shape is unverified, specifies the auth need, and places the tool in the overall workflow. This is sufficient for an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with the single format parameter already documented as 'Leave as json; Yahoo serves XML otherwise.' The description adds no additional parameter-level meaning, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns the fantasy games the authenticated user plays, using a specific verb-like framing ('Which fantasy games... plays'). It also distinguishes itself from siblings by explicitly marking itself as the starting point that provides the game_key needed by other Yahoo tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives strong contextual guidance: 'START HERE — everything else needs a game_key from this.' This clearly tells the agent when to use it first in a Yahoo fantasy workflow, though it does not name specific sibling tools as alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_broadcast_region_getA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safe read-only nature is covered. The description adds behavioral context beyond annotations by specifying the return fields ('Returns: {id, name, timezone}') and explicitly stating 'Auth: none needed', which are not in the annotations or schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two short sentences and a return line. Every piece of information (verb, resource, return shape, auth) earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter read-only tool with strong annotations, the description is complete. It states what is returned, mentions auth requirements, and the schema provides the parameter source. No output schema exists, but the return format is explicitly listed, covering the essential context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the single parameter 'regionId' is fully documented in the input schema. The description only says 'by id', which adds no new meaning beyond the schema. Baseline of 3 is appropriate since the schema handles the semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Get a single broadcast region by id') and the resource ('broadcast region'). It distinguishes itself from the list sibling tool (afl_broadcast_regions) by emphasizing 'single' and 'by id'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Clear context: it is used to fetch a specific broadcast region by its ID. The ID source is described in the schema ('from the broadcasting region list'), which implies the workflow of listing first then getting. No explicit alternatives or exclusions, but enough context for a simple get-by-id tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_competitions_listA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and idempotency. The description adds useful behavioral context by showing the return structure ({meta, competitions}), stating 'Auth: none needed' and giving a concrete example, which goes 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: one sentence for purpose, a single line for return shape, an example, and auth note. Every part earns its place with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple paginated list tool, the description is complete enough. It provides the return shape, an example invocation, and auth requirements. The schema and annotations cover safety and parameters, leaving no significant gaps for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both page and pageSize having descriptions, defaults, and constraints, so the schema already handles parameter semantics. The description's example with pageSize adds minimal value beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'List all AFL competitions', which is a specific verb and resource, and gives concrete examples (AFL, AFLW, VFL, SANFL). This clearly distinguishes it from sibling tools like afl_competition_get and similar lists from other sports.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states what the tool does ('List all AFL competitions') and provides an example with pageSize, making the context obvious. However, it does not explicitly mention when to use this vs. alternatives like afl_competition_get, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_compseasons_listA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond annotations by disclosing the return shape (meta.pagination and compSeasons fields) and stating 'Auth: none needed'. It also specifies the data range 2012–present. These details complement the readOnlyHint and idempotentHint annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: one purpose sentence, one return-shape line, and one auth line. Every part is essential and there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with two optional parameters and rich annotations, the description covers purpose, scope, date range, return structure, and auth. No output schema exists, but the description compensates by listing the return fields.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema provides 100% coverage with descriptions for both page and pageSize, including defaults. The description adds no extra parameter-level information, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'List comp seasons across all competitions' with a specific verb and resource, and adds a date range (2012–present). This distinguishes it from siblings like afl_compseason_get and afl_competition_compseasons.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies this is the global listing tool by saying 'across all competitions'. However, it does not explicitly mention alternatives (e.g., afl_competition_compseasons for a single competition) or exclusion criteria, so it stops short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_content_promo_getA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints, so the description supplements this by specifying the return shape and confirming no authentication is required. It does not detail error handling or pagination, but the annotation coverage reduces the burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise lines: purpose, return shape, and auth requirement. It is front-loaded and contains no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only getter with rich annotations and full schema coverage, the description is complete. It adds return structure (not available via output schema) and auth requirements, making it adequate for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with descriptions for both parameters. The description only echoes 'by id' and adds no extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Get a single promo content item by id' with a specific verb and resource, clearly distinguishing it from the sibling list tool. It precisely scopes the operation to a single item retrieval.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'by id' implies the condition for use, and 'Auth: none needed' gives clear context. However, it does not explicitly mention that afl_content_promo_list should be used for fetching multiple promos or provide exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_content_text_getA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, idempotent, and open world, covering safety. The description adds useful behavioral context by specifying the return shape (id, type, title, body, author, references, tags) and explicitly stating no authentication is needed. This goes beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short lines plus a return line, front-loaded with the purpose, and every sentence adds value. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-get tool with one parameter, the description covers purpose, return format, and auth requirements. Since there is no output schema, explaining the returned fields is essential and done. Nothing meaningful is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes the id parameter with clear semantics (Content item id, required, part of URL path) at 100% coverage. The description adds no further parameter detail, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'Get a single text article by id,' which uses a specific verb (get) and resource (text article) and clearly distinguishes from sibling list/photo/video tools. It is unambiguous about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'single ... by id' clearly implies this is for fetching one specific article when you have its id, distinguishing from list/collection tools. It gives clear context for when to use it, though it does not explicitly name alternatives or exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_ladders_getA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is known. The description adds 'Auth: none needed' and the return format, which are useful behavioral context beyond the annotations. It does not contradict annotations, and it clarifies that the data reflects up to the current round (i.e., changes over time).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-sentence purpose, a return type line, a concrete example, and an auth note. Every sentence adds value and there is no redundant fluff. The example is particularly useful for demonstrating the parameter usage.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with one parameter, the description is complete: it explains the purpose, provides the return shape, shows an example call, and states auth requirements. Given the strong annotations and schema coverage, no additional context is necessary. It fully equips an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already has 100% coverage for the single parameter compSeasonId, with a thorough explanation (competition-season id, not calendar year, required). The description only shows an example value (85) without adding new semantics. Since the schema carries the full burden, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns a competition ladder for a specific AFL competition season up to the current round. It uses a specific verb+resource, and the return structure is explicitly outlined. It distinguishes itself from sibling AFL tools by focusing on ladder data as opposed to matches, teams, or seasons.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool: when you need the current or in-progress ladder for a competition season. It does not explicitly list alternatives or exclusions, but it provides clear context through the example and the 'up to a comp season's current round' qualifier. No misleading guidance is present.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_season_getA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, idempotent, and openWorld hints. The description adds valuable context beyond annotations by specifying the return shape ('{meta, seasons:[{id, year}]}') and auth requirements ('Auth: none needed'). This is helpful and consistent 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: three short sentences covering purpose, return value, and auth. Every sentence adds essential information with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-id tool with one parameter, the description is fully complete. It explains the resource, the return shape, and auth. The rich annotations and schema cover the remaining context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage for the single parameter, including a clear description and provenance ('from afl_seasons_list'). The tool description itself adds no additional parameter semantics, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get a single calendar-year season by id.' It uses a specific verb and resource, and distinguishes from siblings like afl_seasons_list (which lists all seasons) and afl_compseason_get (which gets competition seasons) by focusing on a calendar-year season.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context through the parameter description 'Season id (from afl_seasons_list)', indicating a workflow of listing seasons first. It clearly identifies the tool as a single-item fetch but does not explicitly mention when NOT to use it or name alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_teams_idmapA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and side effects. The description adds useful behavioral context beyond these annotations, including the return shape ('Returns: {entityType:'team', idMapResponse:{ids:{'CD_T10':1, ...}}}') and authentication requirements ('Auth: none needed'). This enriches the agent's understanding without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: the main purpose is stated in the first sentence, followed by the return format and auth note. Every sentence provides distinct value with no redundant fluff, making it efficiently structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple parameterless ID mapping tool, the description is complete. It explains the bidirectional mapping, provides an example return structure, and states authentication requirements. The annotations and schema cover the rest, making the description sufficient for an agent to know when and how to invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, and the description correctly implies no inputs are required. With no parameters to document, the baseline of 4 is appropriate; the description adds value by noting the tool takes no arguments, which is consistent with the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Map CD_T* team providerIds to integer aflapi ids (and vice versa).' This identifies the specific resource (team provider IDs) and the operation (mapping to integer AFL API IDs), distinguishing it from sibling ID mapping tools like afl_matches_idmap and afl_players_idmap.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a user needs to convert between CD_T* team provider IDs and integer aflapi IDs, but it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. The intended use is clear from the purpose, but no explicit guidance is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_venue_getA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds the return structure '{venues:[{id, providerId, name, location, state, timezone}]}' and 'Auth: none needed', which are behavioral traits beyond the readOnlyHint/idempotentHint annotations. It does not disclose error cases or rate limits, but for a simple read tool, it is sufficient. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise: three short sentences covering purpose, return format, and auth. Every sentence adds information, with no filler or redundancy. Front-loaded with the main action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description explicitly lists the return fields, making the output contract clear. With one well-documented parameter and annotations covering safety, this is complete for the tool's complexity. The auth note and return format fill the gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% description coverage for the single parameter, including its source and URL path mention. The tool description adds no additional parameter semantics beyond restating 'by id', so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get a single venue by id' — a specific verb and resource. It distinguishes from the sibling afl_venues_list and other getters by focusing on a single venue. The return format is also included, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by matching the parameter description 'from afl_venues_list', indicating the venueId comes from a prior list call. There is no explicit alternative or exclusion, but for a simple get-by-id tool, this is clear enough context. It lacks explicit 'when not to use' guidance, so not a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_baseball_gamesA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as read-only, idempotent, and open-world, but the description adds critical behavioral context: the return shape is from vendor docs and unverified, innings are keyed by number-as-string, and the tool requires an API key. These disclosures go well beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately sized but every part earns its place: purpose, return shape, caveat about unverified shape, example, and auth requirement. The return shape is lengthy but justifiable given there is no output schema. Could be slightly tighter, but overall it is well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, filtering, return shape, authentication, and an example, which is quite complete for a read-only tool with no output schema. It also highlights a key caveat about data reliability and points to the deeper official MLB provider. It lacks details on error handling or rate limits, but these are not critical for a simple query tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are already documented. The description adds a concrete example ({"date": "2024-07-04"}) and reinforces that the tool filters by date or league, but it does not add new meaning to team, league, or season parameters beyond the schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: 'Baseball games (MLB, NPB, KBO and others) by date or league.' It names specific leagues and the filter dimensions. It also differentiates this tool from the official `mlb` provider, making it distinguishable from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: for baseball games by date or league. It also provides an alternative recommendation by noting that the keyless official `mlb` provider offers deeper data for MLB. However, it does not explicitly enumerate exclusions or edge cases, which keeps it from a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_basketball_gamesA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and open-world hints, but the description adds substantial behavioral context: the detailed return shape, the caveat that the shape is unverified and approximate, the season field being a string rather than integer, and the API key requirement. This exceeds what annotations alone provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately long due to the return shape and caveats, but it is logically structured: purpose, return shape, verification warning, example, auth. Every sentence serves a purpose, though the return shape block could be considered verbose. It is concise for the information conveyed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only games listing tool, the description is quite complete: it explains purpose, parameters, return structure, auth, and even disclaims the unverified shape, compensating for the lack of an output schema. Minor gaps exist, such as behavior when no parameters are supplied, but overall it is well-rounded.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all five parameters with meaningful descriptions, so the baseline is 3. The description adds an example and reinforces the date/league query modes, but it does not materially extend beyond the schema's parameter definitions. No parameter explanation is missing.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns basketball games worldwide from multiple leagues ('NBA, EuroLeague, NBL and many more') and highlights the two primary query dimensions ('by date or league'). This differentiates it from sibling tools like apisports_basketball_standings and other sports' games tools, even though a verb like 'list' is implicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives concrete context for when to use the tool: to fetch basketball games by date or league, with an example date payload. It does not explicitly name alternatives or exclusion criteria (e.g., when not to use it vs. basketball standings), but the scope is unambiguous enough for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_football_teamsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide read-only, idempotent, and open-world hints, so the description doesn't need to restate those. The description adds valuable, non-obvious behavioral context: that the return shape is from vendor docs and unverified against a live response, and that an API key is required. This is beyond the annotations and helps set agent expectations about reliability.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-line purpose statement, a return shape block, a caveat, an example, and an auth note. Every section earns its place and is easy to parse. It's not bloated but provides necessary context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that there's no output schema, the description provides the full return shape and flags it as approximate. It also covers auth requirements and a usage example. For a read-only team-list tool with 5 parameters all described in the schema, this is complete and practical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all parameters with descriptions (100% coverage), so the schema does the heavy lifting. The description adds examples and clarifies that 'search' is for names, but it doesn't add detail beyond the schema. Baseline 3 is appropriate since the schema is fully descriptive.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves clubs/teams by league/season, country, or name search, which matches the tool name and distinguishes it from sibling tools like fixtures or standings. It also provides a concise summary of the return shape, reinforcing what this tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description lists the primary filter modes (league/season, country, name search) and gives an example, which helps an agent choose the right parameters. It doesn't explicitly contrast with sibling tools, but the name and description make it clear this is the teams endpoint among many apisports tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_formula1_racesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, open-world, and idempotent behavior. The description goes further by issuing a critical credibility warning: the response shape is 'from the vendor's documentation and has NOT been verified against a live response' and advises to 'treat it as approximate — inspect the actual payload.' It also discloses the auth requirement. These add meaningful context beyond what annotations provide, though it stops short of describing pagination or default parameter behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately sized and front-loaded with the main purpose ('Formula 1 races and sessions for a season'). It includes a return shape outline, alternative tool guidance, a caveat, an example, and auth note—all in a structured order. Slightly verbose due to the multiple caveats, but every section earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description provides a predicted response shape (albeit unverified), gives an example input, names alternatives, and notes auth requirements. It covers the essential aspects for a tool with 4 optional parameters, though it does not clarify the outcome when all parameters are omitted (e.g., does it return all races across all seasons?). Sufficiently complete for a user to understand what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, with each parameter ('next', 'type', 'season', 'competition') having a concise semantic definition. The description adds an example usage with `{"season": 2023}` and mentions 'races and sessions', but does not materially enhance the schema's parameter explanations. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Formula 1 races and sessions for a season', identifying the specific resource and scope. It distinguishes from sibling tools like jolpicaf1 and openf1 by explaining their different coverage (history/live telemetry) and the unique multi-sport key requirement, making the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly names alternatives ('`jolpicaf1` (keyless) covers F1 history back to 1950 and `openf1` (keyless) covers live telemetry') and gives a clear directive: 'prefer those unless you need this one key to span sports.' This provides both when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• balldontlie_mlb_gamesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint, openWorldHint, and idempotentHint. The description adds important context: it warns that the response shape is from vendor docs and has NOT been verified, advising users to inspect the actual payload. It also highlights a notable inconsistency: `away_team` here, but `visitor_team` on NBA/NFL paths. These caveats go beyond annotations and provide critical behavioral guidance.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is fairly concise and packs a lot of essential caveats into a short space. It clearly separates the main action, the return shape, the warning about unverified shape, the example, and auth note. Slightly dense for an AI agent but every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a moderate complexity (5 optional params, no output schema). The description covers key aspects: the known response shape, example usage, critical field-name inconsistencies, and the fact that the shape is unverified. The main gap is that it doesn't describe cursor pagination usage, but the schema does have a cursor parameter. Overall, fairly complete for a simple list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already defines each parameter. The description adds minimal extra semantics beyond stating 'date, season or team' as the main filters, which maps to the parameters. It doesn't elaborate on values or combinations, but the schema covers the basics, so a baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches 'MLB games by date, season or team', which is a specific verb+resource+scope. It also distinguishes itself from the alternative `mlb` provider by noting the official `mlb` provider is 'far deeper', which helps a user choose between the two.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use this tool vs the official `mlb` provider: 'For MLB alone, the keyless official `mlb` provider is far deeper.' This gives clear guidance on when to prefer an alternative. It also notes the requirements for a key (BALLDONTLIE_API_KEY) and provides an example query.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• balldontlie_nba_teamsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context: it warns that the response shape is unverified from vendor docs and that an API key is required. This goes beyond the annotations to inform the agent about data reliability and auth dependencies.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the main purpose, followed by the return shape, a reliability note, example, and auth. Each sentence serves a clear purpose, and there is no wasted content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple parameterless list tool with no output schema, the description provides a complete picture: the exact team list, fields, authentication requirement, and a caution about unverified data. It even includes an example, making it fully self-contained for an agent to use correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so the description does not need to explain any. The baseline for no parameters is 4, and the description still adds context about the required API key, which is relevant. It fully covers what is needed to invoke the tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific resource (NBA franchises) and the scope (all 30 teams with conference and division). It also lists the exact fields returned, distinguishing it from sibling tools like balldontlie_nba_players or balldontlie_nba_games.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description includes an example ('Every NBA team') which implies when to use the tool, but it does not explicitly state when to use it over alternatives or provide exclusions. The usage context is clear but implicit, so a score of 3 is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betfair_event_timelinesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the security profile is covered. The description adds useful context beyond annotations: the return format (a top-level array with nested score structure) and 'Auth: none needed,' which are valuable for an agent. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-sentence purpose, a return format snippet, and an auth note. Every sentence provides unique value with no redundancy or padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, but the description compensates by explicitly listing the return shape. It covers the essential aspects: what data is returned, that it is a top-level array, and that auth is not needed. For a simple batch read tool, this is complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with parameters already documented. The description's reference to 'several ... at once' aligns with the eventIds array parameter but adds no additional syntax or constraints beyond what the schema provides. Thus baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the purpose: 'Live timelines + running scores for several in-play events at once (batch).' This specifies the verb (returns live timelines/scores), resource (in-play events), and scope (several at once), distinguishing it from the singular sibling tool betfair_event_timeline.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the batch use case clear ('several in-play events at once'), implying it is for when you need multiple timelines in one call. It does not explicitly mention alternatives or exclusions, but the batch context is sufficient for an agent to select it over the singular variant.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_market_moversA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds the return structure and explicitly states 'Auth: none needed', which is useful beyond the annotations. It doesn't contradict annotations and provides concrete output shape.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: one line explaining the purpose and one line with the return structure. Every word earns its place, and key facts are front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, read-only tool with strong annotations and a return schema described inline, this is fully complete. The description covers what it returns and authentication requirements, leaving no ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, and the schema is empty with 100% coverage. Baseline for zero parameters is 4; the description doesn't need to explain parameters since there are none. It correctly focuses on output.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it provides 'Racing market movers' — runners whose fixed prices are shortening/drifting. This is a specific, actionable purpose with a clear resource (racing market movers) and distinguishes itself from siblings like betr_race or betr_race_flucs by focusing on price movements.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: if you need racing market movers, use this tool. However, it does not explicitly state when to use this versus alternatives like betr_race_flucs or betr_next5_races, nor does it mention any exclusions or context where it's not appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betr_todays_racesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description adds useful behavioral context: 'Auth: none needed' and a detailed return shape including field names. This adds value beyond the annotations, though it does not describe edge cases like empty results 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and efficient, with three sentences covering purpose, return structure, and authentication. It is front-loaded with the primary action and uses minimal but informative prose, with no irrelevant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with one optional parameter, the description provides all necessary context: what races are included, how they are grouped, the return format with specific fields, and authentication requirements. The lack of an output schema is compensated by the explicit return shape.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, CountryFilter, is fully described in the schema with 'Country filter (0 = all).' The tool description does not add extra parameter guidance, but since schema coverage is 100%, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool returns 'Today's races grouped by code (Thoroughbred / Greyhound / Harness)' with a specific resource and grouping. It also mentions the homepage context, distinguishing it from other race-related tools that focus on individual races or next 5 races.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description indicates the intended usage context ('for the homepage') and provides clear scope ('Today's races'). It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to understand when this high-level grouped listing is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• chesscom_titled_playersA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it as read-only, open-world, and idempotent, and the description adds important behavioral details: output shape (flat list of username strings, not objects), auth requirements ('Auth: none needed'), and the intended chaining to chesscom_player. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely compact: one-line purpose, return type, example, and auth. Every sentence adds value and the core purpose is front-loaded, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter read-only tool with no output schema, the description covers the purpose, output format, example invocation, and auth. It even points to chesscom_player for detail, making it self-contained for an agent to use correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers the single parameter fully with an enum and description (100% coverage), so the baseline is 3. The description adds a concrete example ({"title": "GM"}) and clarifies that the output is usernames only, but does not provide additional parameter semantics beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Every player holding a given FIDE title — usernames only.' It clearly distinguishes from sibling tools like chesscom_player (single player details) and leaderboards, and explicitly states the output is a flat list of username strings. The 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context by showing an example ({"title": "GM"}) and noting that results should be 'feed one to chesscom_player for detail', suggesting a downstream workflow. It does not explicitly list alternative tools or exclusion scenarios, but the purpose and intended usage are sufficiently clear for correct selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketaustralia_teamsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only and idempotent behavior. The description adds valuable context: the exact return shape (teams array with fields, responseError) and authentication requirement (none needed). This goes beyond annotations and is especially useful given there is no output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded. It begins with the core purpose and fields, then gives the return structure and auth note in two additional short sentences. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple catalogue tool with no required parameters, the description covers purpose, scope, return type, and auth. Since there is no output schema, providing the return structure is essential and done well. No significant gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters (format and jsconfig) with descriptions. The tool description adds no additional parameter meaning, so the baseline of 3 applies; it neither enhances nor harms parameter clarity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states the tool is a 'Team catalogue' with specific fields (id, name, short name, colours, logo/badge URLs) across all CA competitions. The resource and scope are explicit, and it clearly distinguishes from sibling cricket tools like cricketaustralia_fixtures or cricketaustralia_players.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: use this tool when you need team catalogue information. It does not explicitly mention alternatives or when not to use it, but the purpose is self-evident and no exclusions are needed for such a straightforward list function.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dabble_competition_fixturesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the bar is lower. The description adds behavioral context such as the response shape (nested markets/prices/selections/teams), decimal odds, and the note that product is engine-derived. It also mentions 'Auth: none needed,' which goes beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded: purpose, sourcing, alternative, return format, example, and auth. Each sentence earns its place, though the inline return structure is somewhat long. Overall, it is efficient without unnecessary fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 providing a full return payload structure. It covers usage, auth, example, and relationship to sibling tools. For a read-only, idempotent tool with strong annotations and schema, this is complete enough for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 provides an example competitionId and points to sibling tools for sourcing, but does not add new meaning beyond what the schema already specifies for parameters like exclude or includeInPlay. It reinforces, rather than extends, parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'All fixtures for ONE competition, each embedding its markets + prices (decimal odds) + selections + teams,' which clearly defines the resource and action. It also differentiates from sibling tools by explicitly pointing to dabble_fixture_details for a full fixture book, making the purpose distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use guidance: it tells the agent to obtain competitionId from dabble_active_competitions / dabble_competitions, offers an example, and states 'For the FULL book of one fixture use dabble_fixture_details' as an alternative. This clearly delineates when to choose this tool over others.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_hist_event_listA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, open-world, and idempotent behavior. The description adds useful context beyond annotations: it mentions the return shape (array of fields), the authentication requirement, and the specific availability condition ('raw round-level data available'). 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: purpose first, then return format, then auth. Every sentence provides necessary information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with no required parameters and full schema coverage, the description provides all essential context: what it returns, the output shape, and authentication. It also includes a usage hint about passing values to the rounds feed, making it self-sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and each parameter has a clear description. The tool description does not add extra meaning beyond the schema, but it does reference the output fields (event_id, year) that pair with the rounds feed, which is somewhat helpful.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists historical events with raw round-level data available, and specifies the return fields. This distinguishes it from sibling tools like datagolf_hist_results_event_list, which list different types of historical events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says the event_id and year can be passed to the rounds feed, giving clear downstream usage. However, it does not explicitly mention when not to use this tool or compare it directly to alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_live_hole_statsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable context beyond annotations: it reveals the exact return structure, the auth requirement (DATAGOLF_KEY), and the live nature of the data (in-progress). This goes beyond what annotations alone convey, enhancing transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-sentence summary of the tool's purpose, a compact return schema example, and an auth note. Every sentence earns its place, and the most important information (what it does) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description compensates by fully specifying the return structure (courses → rounds → holes with avg_score and wave details). It also covers auth requirements and the in-progress scope. With schema covering params and annotations covering safety, this description is complete for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both 'tour' and 'file_format' have descriptive text in the schema. The description does not add additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Live per-hole scoring distributions for the in-progress event' with specifics like avg score, birdie/bogey rates by hole, and AM/PM wave. This distinguishes it from sibling datagolf tools such as datagolf_live_strokes_gained (strokes gained) and datagolf_live_tournament_stats (tournament-level stats), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for the in-progress event' provides clear temporal context, indicating this tool is appropriate when a golf event is live. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to differentiate from pre-tournament or historical tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_matchups_all_pairingsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety is covered. The description adds valuable behavioral context beyond annotations by detailing the return structure and highlighting the authentication requirement (DATAGOLF_KEY), which is not obvious from schema or annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: the first sentence states the core purpose, followed by a brief return structure and auth note. Every sentence provides necessary information without redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although there is no output schema, the description provides a simplified return format that is sufficient for agents to understand the response shape. Combined with readOnly/idempotent hints and the auth note, the description covers all essential aspects for successful invocation and interpretation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage, with all three parameters (tour, file_format, odds_format) fully described. The description adds no extra parameter-level detail beyond what the schema already states, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'All possible tournament matchup pairings for the current event' with Data Golf's model odds, specifying the resource (matchup pairings) and that it covers every player-vs-player price. This distinguishes it from siblings like datagolf_matchups by emphasizing the exhaustive 'all pairings' nature.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context by specifying 'current event', implying this is for ongoing tournaments, and the 'All possible' phrasing sets expectations for comprehensive coverage. However, it does not explicitly mention when to use this instead of alternatives like datagolf_matchups, nor does it state any exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_outrightsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds significant value by disclosing the auth requirement ('needs your own key in DATAGOLF_KEY') and the response structure (event_name, last_updated, books_offering, odds). 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: one sentence for purpose, a return block, and one for authentication. Every element earns its place, with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description includes a detailed return structure, the current-event scope, the number of sportsbooks, and the auth requirement. This is complete for a read-only odds tool with annotations already covering safety.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%; all four parameters have descriptions, enums, and defaults in the input schema. The description's mention of 'win / top-N / make-cut' aligns with the market enum but does not add meaningful details 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool returns 'Outright (win / top-N / make-cut) odds for the current event across ~13 sportsbooks, plus Data Golf's model line.' This identifies the resource (outright odds), scope (current event), and differentiates it from historical or matchup tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it is for 'the current event' and focuses on outright odds, implicitly distinguishing it from historical or in-play tools. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_scheduleA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the exact return structure and the auth requirement (DATAGOLF_KEY), which is useful behavioral context beyond what annotations provide. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very concise, consisting of a clear purpose sentence, a return format example, and a brief auth note. Every line contributes necessary information with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's purpose, return format, auth requirements, and implicitly the optional nature of parameters through the schema and annotations. Given the simple two-parameter read-only design, this is fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters have descriptions in the schema ('tour' with enum values, 'file_format' as response format), giving 100% schema coverage. The description does not add further parameter-specific detail, so it remains at the baseline for high coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Tour schedule — the season's events with dates, courses and locations.' which clearly identifies the tool's purpose: retrieving the schedule of golf tour events. It also includes the return format, distinguishing it from sibling tools like datagolf_rankings or datagolf_pre_tournament.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this tool is for retrieving the current season's tour schedule with dates, courses, and locations. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous enough for an agent to know when to select this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_live_scoringA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, idempotent, and openWorld hints. The description adds valuable behavioral context beyond these: the live-field population caveat, the return structure shape, and the auth behavior ('works without a key; ESPN_FANTASY_COOKIE unlocks more if set'). This enriches the agent's understanding without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the primary purpose in the first sentence. It efficiently packs return structure, a worked example, and auth notes without redundancy. Every sentence adds information, and the structure makes it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only live-scoring tool with no output schema, the description is thorough: it explains the return format with nested fields, highlights the critical live-only behavior, provides a concrete example, and addresses authentication. The 5 parameters, 2 of which are required, are fully covered by the schema, so the description fills the gap with usage context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 does not add parameter-level meaning beyond the schema; it only provides an example call showing game, seasonId, and leagueId. The 'view' parameter is noted as 'Leave as-is' in the schema, but the description doesn't clarify it further. This is acceptable but not exemplary.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource statement: 'Live in-progress scoring for the current period' and elaborates on exactly what data is returned ('points so far and how many roster spots have yet to play'). It clearly distinguishes this live-scoring tool from siblings like espnfantasy_boxscore or espnfantasy_matchups by emphasizing 'Live' and 'in-progress'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use it: for in-progress scoring during the current period. It states the key timing caveat that 'Live fields only populate while pro games are in progress,' which guides the agent on when results will be meaningful. However, it does not explicitly name alternative tools or state when not to use it, so it falls just short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_matchup_scoreA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the bar is lower. The description adds auth details (works without a key, ESPN_FANTASY_COOKIE for more), the return shape, and the fact that it returns only totals, not lineups. This extra context goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with a clear summary. It includes return format, an example, and auth note in a structured way. The 'Also answers this' line is a bit cryptic but does not significantly bloat the text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description provides the return structure, an example request, and auth requirements. It does not explain error cases or pagination, but given the simple nature of returning compact season totals and the 100% schema coverage, this is reasonably complete. The cross-reference to sleeper tools adds a broader answer context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, so the baseline is 3. The description adds a concrete example call with game, seasonId, and leagueId, which clarifies how the required parameters are used together and reinforces the default for game. It doesn't add much detail for optional filters, but the schema covers those adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool returns compact matchup scores for the season, totals only, without lineups, and explicitly contrasts itself with the box score. It also names sibling tools (sleeper_matchups, sleeper_playoff_bracket) it can answer for, helping distinguish from other ESPN tools. This is a specific verb+resource+scope description.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides context for when to use this tool: when you need compact season matchup totals rather than full box scores or lineups. It mentions an alternative (box score) and even cross-references sleeper tools, but does not explicitly state when not to use it or outline an exclusion rule. The guidance is clear but not fully explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espn_game_summaryA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnly/openWorld/idempotent hints, so the description adds value by describing the dependency on a live event id and the shape of the returned data. It also states 'Auth: none needed,' which is useful behavioral context beyond annotations. No contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: purpose first, then dependency explanation, return format, and auth note. Every sentence earns its place, with no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only summary tool with good annotations and full schema coverage, the description is complete. It explains the dependency on espn_scoreboard, outlines the return structure, and notes auth requirements, sufficing despite lacking an explicit output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter already has a clear description. The description adds the note that `event` comes from espn_scoreboard, which slightly reinforces the schema, but overall it largely repeats what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Full summary for one game' and enumerates specific components (box score, scoring plays, drives/play-by-play, leaders, win-probability and odds). This distinguishes it from sibling tools like espn_scoreboard, which lists games rather than providing detailed summaries.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs that `event` is an id from espn_scoreboard and explains why no example is provided ('it needs a live event id, so the doctor probes espn_scoreboard instead'). This gives clear usage context and points to the prerequisite tool, though it doesn't explicitly state when not to use alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• euroleague_clubsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the operation as read-only and idempotent. The description adds value by documenting the return shape, stating that no authentication is needed, and explaining the significance of the `code` field. It does not disclose edge cases, but for a simple read-only list this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: it opens with a clear one-sentence purpose, then lists the return format, an example, and authentication requirements. Every line contributes useful information without unnecessary fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 documents the response structure and includes a concrete example. The annotations cover safety and idempotency, and the input schema covers parameters. The tool is simple enough that no further context is needed for an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema provides full descriptions for both parameters (100% coverage), so the description does not need to add parameter details. It does include an example request with `competition` and `season` values, which slightly aids understanding, but no additional semantic meaning beyond the schema is provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: returns clubs for a season with city, country, and venue details. The example and the note that `code` is used elsewhere further clarify its role. It is distinct from sibling tools like euroleague_games or euroleague_people.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The use case is obvious: retrieve clubs for a EuroLeague/EuroCup season. The example request and the explanation of the season code provide clear context. No explicit alternatives are mentioned, but none are needed since this is the only EuroLeague club-listing tool among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• euroleague_gameA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, and the description adds further useful context: 'Auth: none needed' and a clarification that the response is 'a single object, NOT wrapped in {data}'. These details go beyond the structured annotations, though it doesn't cover error behavior 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: a one-line purpose, a return shape summary, an example, and an auth note. Every sentence contributes useful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool, the description covers the key aspects: what it returns (including the exact fields), an example call, and auth requirements. Given the annotations and schema already handle safety and parameter details, this is complete enough for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, with each parameter clearly explained. The description's example demonstrates a valid call but adds little semantic value beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'One game's detail by its per-season game code.' It clearly distinguishes from sibling tools like euroleague_games (likely a list) and euroleague_game_stats (statistics) by focusing on a single game's full detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: to get one game's detail using its per-season game code. However, it does not explicitly mention alternative tools (e.g., euroleague_games for multiple games) or exclusions, so it falls short of the explicit alternative guidance seen in top-tier examples.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• euroleague_peopleA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond readOnly/openWorld/idempotent annotations, it alerts users that the response is ~600 KB and must be paged, and it specifies the return shape ({total,data:[...]}) and that no auth is needed. This adds operational context not present in annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is compact: two sentences plus example and auth line. The size warning is front-loaded, and every line adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema, so the return field list is helpful. With annotations covering read-only/idempotency, schema covering all params, and description covering pagination and example, the tool is adequately specified for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers all 4 parameters with descriptions (season required, limit/offset paging, competition enum). The description's example illustrates parameter usage but does not add significant new semantics 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states it returns 'Players and coaches registered for a season,' naming the resource (people) and scope (season). This distinguishes it from sibling Euroleague tools like euroleague_game or euroleague_seasons by content type.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: it's for retrieving season rosters, warns about large size and recommends pagination. However, it does not explicitly contrast with sibling tools or state when not to use it, so it falls short of explicit alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• formulae_driver_standingsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as read-only, open-world, and idempotent. The description adds behavioral details about the response format—a top-level array with specific fields—and notes no authentication is required.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact but informative, covering purpose, return format, example, and auth. The inclusion of the full return field list is somewhat lengthy but provides necessary detail without an output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, one-parameter read-only tool, the description sufficiently covers usage and output shape. Lacks any mention of ordering or filtering, but the schema and annotations provide a clear picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter championshipId is fully described in the schema as a championship UUID. The description supplements this with a concrete example value and clarifies that the standings are for that season.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it returns drivers' championship standings for one season. The name and description together distinguish it from team standings and other motorsport standings tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides context on when to use (for driver standings per season) and includes an example of the required championshipId. Does not explicitly mention alternatives, but the description is clear enough that sibling tools like formulae_team_standings would be chosen for team standings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_my_teamA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/idempotent annotations, the description discloses the 403 auth failure, the selling_price/purchase_price difference and its transfer-affordability impact, the pre-deadline unlimited transfers status edge case, and the chip_type routing distinction. It also explains that the response was 'VERIFIED against a live squad', adding confidence.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose and contains valuable return-structure details, but it is verbose and repeats auth information in multiple places: 'Needs your FPL session cookie', 'Returns 403 ... without FPL_SESSION_COOKIE', and 'Auth: works without a key; FPL_SESSION_COOKIE unlocks more if set.' The all-caps edge-case callouts are useful but make it longer than necessary.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 compensates with a full JSON return shape for picks, chips, and transfers, including enums and null semantics. It also covers failure modes, authentication requirements, an example call, and cross-tool equivalence, making it unusually complete for a one-parameter endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema description coverage for the single managerId parameter, the schema already documents that it is 'Your own manager id' and required as part of the URL path. The description adds only a reinforcing example ('{"managerId": 1}') and does not provide additional parameter nuance beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description opens with 'YOUR current squad including picks not yet visible to others, plus bank, free transfers and chip availability', naming the exact resource and scope. It is clearly distinct from generic squad/pick tools because it emphasizes the current user's own team and the additional bank/transfer/chip data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: it 'Needs your FPL session cookie', notes 403 without it, and the schema says it 'only ever returns YOUR squad', which excludes other managers. It references cross-platform equivalents ('Also answers this: espnfantasy_rosters, sleeper_league_rosters, yahoo_team_roster') but does not explicitly say when to prefer this over FPL sibling tools like fpl_manager_picks or fpl_squad.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• jolpicaf1_lapsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a read-only, idempotent operation. The description adds valuable behavioral context: the large payload requiring pagination, the exact return shape, and confirmation that no auth is needed. This exceeds what annotations alone provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: purpose, size warning, return structure, example, and auth in a few sentences. Every sentence earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 carries the burden of explaining the return structure, which it does explicitly with a nested type sketch. It also covers pagination, example usage, and auth, making it complete for a data-retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents parameters. The description adds an example call but does not go beyond the schema in explaining parameter semantics. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Lap-by-lap times for every driver in a race' – a specific verb and resource. This distinguishes it from siblings like results, qualifying, and pitstops within the same F1 family.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description warns 'LARGE — page it or narrow to one lap', providing clear context on when and how to use the tool. It also includes a concrete example with season/round and limit. It does not explicitly state when NOT to use it versus alternatives, but the purpose distinction is evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_marketsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by specifying the return format (detailed fields list), pagination behavior via cursor, and that no auth is required. It also clarifies the catalog scope ('current quotes'), going 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the core purpose. The return block and example are useful but slightly lengthen the description. Each part earns its place, though the long field list could be considered verbose; however, it preempts output-schema ambiguity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 6 optional parameters, no output schema, but the description compensates by providing the exact return shape and an example request. It also covers auth and pagination. Missing are rate limits or edge cases, but given the read-only annotations and simplicity, this is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters, so baseline is 3. The description adds meaning by explicitly mentioning the filter options (event/series ticker, status) and providing a concrete example ({'limit': 5, 'status': 'open'}) that demonstrates how to use parameters together. This exceeds the schema's dry parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Prediction-market catalogue with current quotes' with specific verbs ('filter') and resource (market catalogue). It distinguishes from siblings like kalshi_market (single market) and kalshi_events (events) by focusing on listing/filtering markets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: filter by event/series ticker or status, paginated by cursor, and mentions 'Auth: none needed.' The line 'Also answers this: polymarket_markets, polymarket_clob_markets' hints at substitutability, but there are no explicit exclusions or precise when-to-use vs alternatives guidance for other siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_series_listA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context by stating 'Auth: none needed' and specifying the exact return fields. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, with a clear primary statement, a return structure snippet, a helpful example, and an auth note. Every sentence adds value and the example improves comprehension without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with no output schema, the description covers purpose, return format, example usage, and authentication. It's sufficiently complete for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters already described. The description adds an example usage for 'category' but doesn't elaborate on 'include_product_metadata', so it's at baseline for schema-driven semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists all series in a category, giving a specific verb-resource relationship. It differentiates from siblings like kalshi_series by noting it's at the 'top of the id chain' and uses 'All series in a category'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context with example categories and an explicit usage example (Sports category). It doesn't name alternatives or list when-not-to-use, but the hierarchy hint and return structure imply its role among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_tradesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context: it's a public data endpoint ('Auth: none needed'), it's paginated by cursor, and it returns a specific trade structure. This goes beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a clear one-line overview, a returns specification, an auth note, and a sibling cross-reference. Every sentence adds value with no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list-style tool with complete schema coverage and helpful annotations, the description is fully adequate. It covers the return shape, filter capability, pagination, auth requirements, and addresses a potential sibling ambiguity. No critical information is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers 100% of parameters with descriptions. The description adds only the note that ticker is optional and that pagination uses a cursor, which aligns with existing schema details. Baseline of 3 is appropriate since the schema already does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as retrieving 'Recent public trades' with an optional market ticker filter, which is a specific resource and action. It also differentiates from the sibling tool polymarket_trades by noting it 'Also answers this: polymarket_trades,' explicitly distinguishing its scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear usage hint by mentioning that it also answers polymarket_trades queries, which is an explicit alternative. However, it lacks more detailed when-to-use or when-not-to-use guidance, and the cross-reference could be more explicit about when to choose which tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• laliga_competitionsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds context beyond annotations: the return structure and an auth note ('works without a key; LALIGA_SUBSCRIPTION_KEY unlocks more if set'), which clarifies data availability and key requirements. This is useful, though it does not discuss pagination, rate limits, or errors.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: three short paragraphs covering purpose, return format, and auth. Each sentence earns its place, with the purpose front-loaded. No redundant or vague wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list tool, the description is complete. It covers scope, return fields, and auth behavior. Even without an output schema, the return structure is explicitly provided, and annotations cover safety. Little else is needed for accurate invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters and the schema is empty, so the baseline is 4. The description adds no parameter information because none exist; the schema is fully self-explanatory. No compensation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'All LaLiga competitions' with specific scope (men's/women's, primera/segunda, across history) and lists key fields (slug, opta_id, name). This specifies a distinct resource and scope, differentiating it from sibling tools like laliga_competition (singular) which likely fetches a single competition.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by describing the resource ('All LaLiga competitions') but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or sibling tools. The auth note provides some context but no direct comparison to other laliga_* tools, so guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• laliga_squadA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already state readOnlyHint, openWorldHint, and idempotentHint. The description adds value beyond these by disclosing auth behavior ('works without a key; LALIGA_SUBSCRIPTION_KEY unlocks more if set') and clarifying that the required subscription parameter does not change the current-roster scope. It also provides the return structure, which is useful context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: a definition of the returned data, a return-format structure, and an auth note. Each sentence is purposeful, with no redundancy or filler, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with only two parameters and no output schema, the description covers everything needed: what the tool returns (with nested fields), the required parameters' roles, auth requirements, and a clarification about the subscription argument. It is complete for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for both parameters, so baseline is 3. The description adds semantic value by explaining that the subscription argument is required but does not affect the historical/current scope, and it clarifies the slug with an example in the schema. This extra context goes beyond the bare parameter names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'A club's CURRENT squad' with a list of player attributes (person, photos, position, shirt_number, etc.). It distinguishes from season-historical data by explicitly noting the roster is current, not historical, and the tool name 'laliga_squad' aligns with this purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by emphasizing 'CURRENT squad' and clarifying the subscription parameter, but it does not explicitly mention when to use this tool over sibling tools like laliga_team or laliga_matches. No alternatives are named or exclusions given, leaving usage guidance implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• laliga_subscriptionA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description's added value comes from disclosing the return shape (exact subscription object structure) and auth behavior (works without a key; LALIGA_SUBSCRIPTION_KEY unlocks more). This is useful context beyond the annotations, though it could further explain what 'unlocks more' entails or error scenarios.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: first sentence states purpose and key usage guidance, second provides exact return shape, third covers auth. Every sentence serves a distinct purpose with no fluff, and the most critical information (slug-based lookup and teams alternative) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description fully specifies the return structure, so the agent knows what to expect. It also covers auth prerequisites, the single parameter, and distinguishes from a closely related sibling. For a simple read-only single-resource tool with strong annotations, this description is complete enough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: the single 'slug' parameter is fully described with an example (laliga-easports-2025 = 2025/26) and required status. The description only reiterates 'by slug' and adds no new semantic detail beyond the schema, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as retrieving a single season instance by slug, listing the exact data fields (competition, year, season name, current gameweek, rounds, teams). It also explicitly differentiates from the sibling laliga_teams by declaring this tool's teams list as 'authoritative' for a season roster, making the tool's unique purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit guidance to use this tool instead of laliga_teams for a season roster, which is a clear when-to-use/alternative statement. It implies use for a specific season subscription by slug, but does not explicitly mention when to use the sibling laliga_subscriptions (plural) for listing all seasons, leaving a minor gap in alternative coverage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_tools_by_capabilityA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral context: it returns only 'enabled' tools, works across providers, and the default no-argument behavior returns the full capability→tools map. This goes beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-sentence purpose statement followed by a clear example and default behavior. Every sentence contributes value with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple tool (one optional parameter, existing output schema, strong annotations), the description is complete. It covers both invocation modes (with and without the capability argument) and relies on the output schema for return details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already provides full parameter documentation. The description only adds a different example slug ('sport.event_markets') and repeats the default behavior, which does not significantly enhance meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: discovering tools by capability, with a specific verb ('returns') and resource ('every enabled tool exposing it across providers'). It distinguishes itself from sibling listing tools by focusing on capabilities and cross-provider comparison, which is unique.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: to find tools exposing a given capability or to list all capabilities. It gives a concrete example slug and explains the no-argument behavior, though it does not explicitly name alternatives or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_allstar_ballotA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by specifying the return structure and explicitly stating 'Auth: none needed,' which provides useful behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: purpose first, then return shape, then auth. Every sentence adds necessary information with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter read-only endpoint with no output schema, the description adequately covers the return format and auth requirements. It provides enough information for an agent to use the tool effectively without additional context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with both parameters described (season as 'Season year' and leagueId with specific AL/NL ids). The description's mention of 'league + season' adds no new meaning beyond the schema, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns All-Star Game ballot candidates filtered by league and season. The verb 'Returns' and resource 'ballot candidates' are specific, and the league/season scoping distinguishes it from siblings like write-ins and final vote.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this is for retrieving ballot candidates for a specific league and season. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous, making it easy for an agent to know when to invoke it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_awardsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint, openWorldHint, and idempotentHint, and the description does not contradict them. It adds useful context beyond annotations: the exact return shape ({awards:[{id, name, season, player, team, votes}]}) and that no authentication is needed. This is helpful but not exhaustive (no mention of error cases or pagination), justified by the strong annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences: purpose with examples, pointer to related tool, and return/auth notes. Every sentence adds value with zero fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with one required parameter, the description covers purpose, related tool, return structure, and auth requirements. Combined with full schema descriptions and safety annotations, it is fully sufficient for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers all 3 parameters with descriptions and defaults, so the baseline is 3. The description adds marginal value by pointing to mlb_awards_list for awardId discovery and repeating examples, but it does not materially enhance parameter understanding beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns award recipients, listing specific award IDs (MLBHOF, ALMVP, etc.) and explicitly points to mlb_awards_list for discovering award IDs. This gives a specific verb+resource scope and distinguishes it from the related sibling tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It says 'Discover awardIds with mlb_awards_list', which provides a clear complementary workflow and implies using this tool when you already know the award ID. However, it does not explicitly state when not to use this tool or contrast with other MLB tools, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_seasonA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds value by stating the exact return shape and noting 'Auth: none needed,' which is useful context beyond the structured metadata.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and front-loaded with the purpose in the first sentence. The return shape and auth note are included without any waste, making every line valuable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with rich annotations, a complete inline return shape, and only 2 parameters fully described in the schema, the description provides all necessary context. The tool's scope is narrow, and this description is sufficient for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description reinforces that seasonId is the required parameter and part of the URL path, but it does not add substantial meaning beyond the schema, which already documents seasonId and sportId.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly identifies the tool as providing single-season detail by seasonId, specifically key dates and game-count info. It distinguishes itself from sibling tools like mlb_seasons and mlb_schedule by focusing on season metadata rather than listing all seasons or game schedules.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Single season detail by seasonId' clearly signals when to use this tool—when you need key dates and game-count info for one specific season. It does not explicitly name alternatives or exclusions, but the context is clear enough among the mlb_* sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_teamsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already mark this as read-only, open-world, and idempotent, and the description adds the fact that authentication is not needed and the specific return shape. This is valuable context beyond the annotations, though it does not describe pagination or rate limits, which are likely unnecessary for a small catalogue.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only three sentences, front-loaded with the core purpose and fields, followed by usage guidance, return format, and auth. Every sentence contributes new information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple listing tool with all optional parameters and no output schema, the description provides the essential context: what it returns, how to invoke it for the common case, and that no auth is needed. The lack of pagination or filter examples is acceptable given the low complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all four parameters with descriptions, and the description reinforces sportId's role by giving a concrete value ('sportId=1'). It does not elaborate on season, hydrate, or leagueIds, but the schema already documents these sufficiently.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a 'team catalogue' listing id, name, abbreviation, location, league/division, and home venue. The added 'Pass sportId=1 for the 30 MLB clubs' narrows the scope and distinguishes it from related MLB team tools like mlb_teams_history or mlb_teams_stats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit instructions for the primary use case (sportId=1 for MLB) and notes that auth is not required. However, it does not explicitly exclude alternatives such as mlb_team for a single team or other sport-specific team tools, though the sibling list implies a generic catalogue purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_transactionsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only/idempotent behavior. Description adds the specific transaction categories covered and the exact return object structure, plus auth requirement. It does not mention pagination or default ranges, but with openWorldHint the bar is lower.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short paragraphs: first states purpose and filters, second gives return shape and auth. Zero filler, information is front-loaded and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only query tool with six optional params and no output schema, it provides purpose, return format, auth status, and filter semantics. Sufficient for an agent to invoke correctly without further context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers all six parameters with descriptions, so baseline is 3. The description restates filtering by team/player/date but adds no syntax or relationship details beyond schema, which already notes startDate must accompany endDate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly identifies tool as retrieving MLB roster transactions, listing concrete examples (signings, trades, call-ups, IL moves, DFA). It also states filter dimensions (team, player, date), distinguishing it from sibling tools like mlb_teams or mlb_schedule.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Description specifies filter options (by team, player, single date, or range) and notes authentication is not needed, giving clear context for invocation. It does not explicitly mention alternatives or when-not-to-use, but the scope is well-defined.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• motogp_categoriesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds valuable context beyond annotations: the exact return structure, the semantic meaning of the id field, and the absence of authentication requirements. No contradictions found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: a one-line definition, a return format specification, an example, and an auth note. Each section earns its place with no redundant information, and the main purpose is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that the tool has only one parameter, full schema coverage, and strong annotations, the description provides sufficient additional context: return format, field semantics, a concrete example, and auth requirements. It is complete for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single parameter eventUuid, which is described as 'Event uuid from motogp_events.' The description adds a concrete example UUID, but this does not fundamentally enhance understanding beyond 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly defines the tool as returning the classes/categories (MotoGP, Moto2, etc.) running at a specific event. It specifies the output fields and connects to other motogp tools (sessions, standings), distinguishing it from sibling tools like motogp_events or motogp_standings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states that the returned `id` is the categoryUuid needed by session and standings tools, providing clear use-case context. It also includes an example and notes that no auth is needed, but it does not explicitly mention alternatives to avoid or conditions when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• motogp_eventsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly/openWorld/idempotent; the description adds the return schema, an example, and explicit auth requirement ('Auth: none needed'). This supplements the structured hints without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Compact labeled sections (summary, returns, example, auth) convey maximal useful information without waste. The example JSON is integral to understanding the return shape.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, so the description compensates by fully listing return fields and providing an example. Combined with the rich input schema and annotations, it is complete for a read-only list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% parameter coverage, describing both seasonUuid and isFinished with helpful guidance. The description's example reinforces usage but does not add material semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies the resource ('Grand Prix weekends in a season') with key attributes (circuit, country, dates) and a return structure. This clearly distinguishes it from sibling tools like motogp_sessions and motogp_seasons.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example and note that seasonUuid comes from motogp_seasons give clear usage context. It does not explicitly name alternative tools or state when not to use it, but the intended use case is evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• motogp_sessionsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints, which cover safety. The description adds that no authentication is needed—a useful behavioral fact—and clarifies the exact return structure with session type enums. No contradictions 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: a one-line summary, a return type definition, a concrete example, and an auth note. Every section earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with two parameters and no output schema, the description fully covers inputs, outputs, and usage. It provides the return fields, an example, the race-selection hint, and auth requirement, making it self-sufficient for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents both parameters, including that both are required and one alone returns 400. The description's example with real UUIDs adds context but no additional semantic meaning beyond the schema, so the baseline of 3 applies given 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning session data (practice, qualifying, sprint, race) for one class at one event. It distinguishes itself from sibling tools like motogp_standings and motogp_session_classification by focusing on session listings rather than results or standings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete example showing how to request MotoGP sessions for a round, and includes guidance to pick type 'RAC' for the race. It clearly implies when to use the tool, though it does not explicitly name alternative tools or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nascar_race_listA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context by flagging the payload as LARGE (~430 KB), which helps agents prepare for a big response. It also includes the return structure and authentication requirements, going 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear first sentence, a size warning, an explicit return-format block, an example call, and an auth note. Every section serves a purpose and nothing is redundant. It is longer than a one-liner but earns its length by providing concrete output structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with no output schema, the description is remarkably complete. It specifies the exact return shape with all field names, clarifies the series mapping (1=Cup, 2=Xfinity, 3=Truck), gives an example, and notes the large response size. No important usage context is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the single parameter, 'season', is documented in the schema as required. The description adds only an example ({'season': 2024}) and mentions in the schema that it's part of the URL path, but it does not add material semantic detail beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool returns 'Every race in a season across all three series' with a specific list of included data fields (winner, track, distance, cautions, lead changes). This is a specific verb+resource combination that distinguishes it from sibling tools like nascar_weekend_feed by scope (season-wide vs. weekend-specific).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes it clear when to use this tool: when you need all races in a season across the three NASCAR series. It does not explicitly name alternatives or exclusions, but the scope is unambiguous. No when-not-to-use guidance is provided, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_ladderA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds valuable behavioral context beyond annotations by stating 'Auth: none needed' and describing the exact return payload structure (type, count, data array with fields), which helps the agent understand what to expect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: it opens with the purpose, clarifies the year parameter, lists the return format, provides an example, and ends with auth. Every sentence serves a distinct purpose, with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only standings tool with two parameters and no output schema, the description is fully adequate. It covers the purpose, parameter semantics, return fields, an example, and auth requirements. Combined with the annotations (read-only, open-world, idempotent), the agent has all necessary information to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description reinforces the `year` mapping and provides an example ({'year':2025,'seasonType':'regular'}), but the parameters are already well-described in the schema (e.g., 'Season START year', enum values). The example adds marginal value but does not introduce new semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning the NBL ladder (standings) for a season, including the specific data fields (position, played/won/lost, points_percentage, etc.) and the number of clubs (10). It distinguishes itself from sibling tools like nbl_schedule or pl_standings by focusing on the ladder resource and season scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on how to invoke the tool, including the meaning of the `year` parameter with the 2025=NBL26 mapping and the `seasonType` values, plus a concrete example for the current season. It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to know when to select this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_team_rosterA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the return shape and 'Auth: none needed', which are useful behavioral details not covered by annotations. No contradiction found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the core purpose, followed by a structured returns line and a single auth note. Every sentence provides value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only roster lookup, the description covers purpose, parameter sourcing, output structure, and authentication requirements. The schema handles parameter details, and the return shape in the description compensates for the lack of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both parameters (year, teamId) fully documented including the meaning of year and the source of teamId. The description does not add new parameter semantics beyond the schema, so the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'One team's roster for a season', specifying the verb (roster) and the resource scope (one team, one season). It also points to where teamId comes from, distinguishing this from sibling tools like nbl_players, nbl_schedule, and nbl_ladder.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description tells the user that teamId must come from nbl_players/nbl_schedule/nbl_ladder team objects, which implies a prerequisite step. It lacks explicit comparison with alternatives or when-not-to-use guidance, but the purpose is specific enough to infer appropriate usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhl_boxscoreA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds useful behavioral context beyond annotations: the full return structure, an example request, and 'Auth: none needed.' It does not contradict annotations and enriches the agent's understanding of what to expect. Not a 5 because it lacks error/edge case handling details, but annotations lower the bar.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a concise purpose sentence, a detailed but formatted Returns block, an example with request body, and an auth note. Each section earns its place, and the purpose is front-loaded. It is appropriately sized for the complexity of the return payload.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 specifies the return shape including both team lineups and player-level stats. It also provides an example and auth requirements. For a single-parameter tool, this is complete: an agent can confidently invoke it and interpret the response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single parameter, and the schema already explains gameId as the NHL game id from nhl_schedule/nhl_scores and notes it's part of the URL path. The description adds an example gameId value, but that is a minor addition. Baseline 3 applies since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns the 'Full box score for one game' with specific stat categories (goals, assists, plus-minus, shots, hits, blocks, time on ice). This specific verb+resource+scope distinguishes it from sibling tools like nhl_scores (summary scores) and nhl_game_landing (likely a broader game view).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The parameter description instructs that gameId comes from nhl_schedule / nhl_scores, implying a prerequisite workflow. While it doesn't explicitly name alternatives or exclusions, the context is clear: this tool is for detailed box score data for a single game, and it indicates a dependency on other tools for obtaining the ID.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhl_skater_leadersA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which cover basic safety. The description adds useful behavioral context: 'Auth: none needed' and a detailed return structure, which helps the agent understand what to expect without exceeding the annotation coverage. No contradictions found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise and well-structured: the main purpose in one line, a compact return format summary, and a single example. Every sentence adds value, with no redundant or fluff content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description provides a full return structure, an example request, and auth requirements. It covers purpose, parameters, and expected output, making it self-sufficient for a simple read-only stats tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds value with an example showing valid parameter combinations (e.g., 'season_or_current': 'current', 'limit': 10), and the return structure clarifies how parameters like categories map to output fields. This goes slightly beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'League leaders among skaters' with a specific list of categories (goals, assists, etc.). It distinguishes itself from the sibling tool nhl_goalie_leaders by explicitly targeting skaters, making the resource and scope unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for what the tool does, but it does not explicitly state when to use it versus alternatives (e.g., nhl_goalie_leaders) or mention exclusions. The example gives usage context, but the guidance is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nrl_fixtureA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds that no authentication is needed and provides the full return shape, which goes beyond the annotations. It confirms read-only, idempotent behavior implicitly through 'full fixture + results' and the return specification. It doesn't disclose rate limits or other side effects, but the annotations already cover the safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a one-sentence purpose, then tight usage, return format, example, and auth note. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter tool, the description covers purpose, input source, example, return format, and auth. The explicit return JSON compensates for the missing output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema already explains the competitionId source and requirement. The description adds an example value (12999) and the context that it's for a competition, but this is mostly redundant with the schema's description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource: 'Full fixture + results for one competition' and lists the exact fields returned. It also differentiates from nrl_match by explicitly saying 'resolve the matchId for nrl_match,' making its role clear among siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear usage: 'Use it to list a round's games and to resolve the matchId for nrl_match.' It also explains where to obtain competitionId (from nrl_competitions / nrl_application_settings). However, it doesn't explicitly state when not to use this tool or name other alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nrl_matchA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which cover safety and mutability. The description adds valuable behavioral context: the full return JSON structure, the note 'Auth: none needed,' and the pointer to stat code definitions. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with a clear summary. It efficiently covers contents, return shape, an example, and auth in a compact, information-dense format. Every sentence contributes value, and the structure makes it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 bears the burden of explaining the return value—it does so comprehensively with a detailed JSON structure. It also covers the scope of data (stats, rosters, sin bins, reports), provides an example, and mentions auth and stat code decoding. This is complete for a read-only data retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both matchId and competitionId already explained in detail ('Required — part of the URL path'). The description adds an example JSON usage, which reinforces parameter meaning but doesn't introduce new semantics beyond 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Full match file: per-player match statistics' and 'This is the per-player, per-match stat source.' It specifies the resource (match file), scope (per-player, per-match), and distinguishes itself from siblings like nrl_fixture by being the detailed stat source.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool ('per-player, per-match stat source') and provides a concrete example. It also directs users to decode stat codes via nrl://stats/definitions. However, it doesn't explicitly mention alternatives or when not to use it, which prevents a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opendota_playerA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds value by detailing the exact return fields, the rank_tier encoding (tens=medal, units=star), and that MMR is 'estimated.' It also explicitly states 'Auth: none needed,' which is useful behavioral context beyond the annotations. No contradictions exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: a one-sentence summary, a Returns block, an example, and an auth note. It is front-loaded with the core purpose and every section serves a specific informational role without unnecessary verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only one parameter and no output schema, the description fully compensates by explaining the return fields, rank_tier encoding, and providing an example. It covers auth requirements and the nature of the data (estimated MMR), making it complete for a simple read-only profile lookup tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes account_id with a precise explanation (Steam 32-bit, not 64-bit, required, part of URL path). The description's example ('account_id': 88367253) reinforces usage but does not add substantial new meaning beyond the schema. With 100% schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'A player's profile with rank tier and estimated MMR,' identifying the specific resource and data. It distinguishes itself from siblings like opendota_player_matches and opendota_player_winloss by focusing on profile/rank information, and it includes a detailed return structure with an example.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use this tool to fetch a player's profile with rank tier and MMR, with an example and a note that auth is not needed. It does not explicitly state when not to use it or mention alternatives, but the purpose is unambiguous for this simple read-only tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opendota_player_matchesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is known. The description adds meaningful behavioral context by disclosing how to interpret a win ('(player_slot < 128) == radiant_win') and noting 'Auth: none needed.' It also specifies the return structure, which is especially valuable because there is no output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence purpose, a return-format block with win interpretation, a minimal example, and an auth note. Every element earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description fully discloses the return fields and the win heuristic, which are essential for understanding the response. It also covers auth requirements and provides a working example. Combined with thorough schema parameter descriptions and safety annotations, the tool is sufficiently complete for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all four parameters (account_id, win, limit, hero_id) are already well-documented in the input schema. The description's example repeats account_id and limit usage but adds no new semantic detail beyond the schema, thus meeting the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'A player's recent matches with hero, result and KDA,' which uses a specific verb (retrieve/list) and resource (player matches) and clearly distinguishes it from sibling tools like opendota_player_winloss or opendota_player_heroes by focusing on the match history with performance stats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context (recent match history with hero, result, KDA) and a concrete example invocation, but it does not explicitly mention when to use this tool over alternatives such as opendota_player_heroes or opendota_match. The example implies typical usage but lacks explicit exclusions or alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_car_dataA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context beyond these: the ~3.7 Hz sampling rate, the high-volume warning, the top-level array return shape, and 'Auth: none needed.' This helps the agent understand scale and filtering requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded. The first sentence states the core purpose, followed by a high-volume warning and a compact return-type example. No unnecessary words or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description lists all return fields and warns about result size. It also includes auth details and suggests how to constrain results. For a read-only telemetry tool with three parameters, this is complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with descriptions for meeting_key, session_key, and driver_number. The description reiterates that session_key and driver_number must be passed and explains the volume issue, but this largely mirrors the schema description for driver_number. It adds no new syntax or format details, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Car telemetry at ~3.7 Hz — speed, throttle, brake, gear, RPM, DRS,' which clearly specifies the resource and data type. This distinguishes it from sibling tools like openf1_laps or openf1_position that cover different data. The verb 'telemetry' conveys the exact nature of the output.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance: 'HIGH VOLUME: always pass session_key + driver_number' and advises using date>=/date<= operators to window results. This tells the agent when and how to invoke the tool, though it does not explicitly list alternatives or when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_driversA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the bar is lower. The description adds useful context: 'Auth: none needed' and that the return is a top-level array. It also implies behavior for 'latest' values. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise: one sentence for purpose, one for return format, and one for auth. It is front-loaded with the primary action and includes all necessary detail without any filler. Every line earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 5-parameter, optional-filter list tool with no output schema, the description compensates by explicitly listing the return fields and their structure. It covers session scoping, the latest option, and auth context. Combined with strong annotations, the overall context is complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed descriptions for all 5 parameters, so the baseline is 3. The description only reiterates session_key usage ('Pass session_key or latest') and adds no extra semantics for team_name, name_acronym, driver_number, or meeting_key beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the resource ('Drivers entered in a session'), the key scope ('Pass session_key or latest'), and the fields returned. It distinguishes itself from sibling tools like openf1_championship_drivers by emphasizing session-level data. This is a specific verb+resource+scope definition.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use it to get drivers entered in a session, and explicitly recommends passing session_key (or 'latest') to bound the response. However, it does not explicitly state when not to use it or mention alternatives like championship_drivers or jolpicaf1_drivers, so it falls short of a full when/when-not justification.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_starting_gridA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description discloses critical behavior: the 404 'No results found' response for sessions without published grids, and the exact return shape. This saves the agent from misinterpreting errors and provides parse-time expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose. The sparse feed caveat, return format, and auth note each add essential information without redundancy. No word is wasted.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with no output schema, the description covers all necessary aspects: what the data is, the expected return structure, potential error conditions, and authentication requirements. It is fully self-contained for an agent to invoke and parse results correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all three parameters (position, meeting_key, session_key) at 100% coverage. The description adds no additional nuance about parameter usage or relationships, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns the race starting grid with per-driver grid position and lap time. It lacks an explicit action verb, but the resource and scope are unambiguous. It is distinguishable from sibling OpenF1 tools by the specific focus on grid data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The sparse feed warning clearly tells the agent when to expect 404 errors, which is essential context for deciding whether this tool is appropriate. It does not explicitly name alternative tools or exclusion criteria, but the guidance provided is clear and practical.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_stintsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/idempotent/openWorld annotations, the description adds 'Auth: none needed' and enumerates the exact return fields, providing useful behavioral context. It does not contradict annotations and no negative behaviors are hidden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise lines: purpose, return signature, and auth. Every sentence carries value and the structure is front-loaded with the main intent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even without an output schema, the description fully specifies the return array and its fields, plus auth requirements. For a simple read-only list endpoint with well-documented parameters, this is complete and self-sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already explained (e.g., 'Filter by tyre compound'). The description merely echoes 'compound' and 'tyre age' without adding new semantic details, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Tyre stints — compound and tyre age per driving period' and explicitly lists the return fields (stint_number, driver_number, lap_start, lap_end, compound, tyre_age_at_start, session_key), giving a specific and unambiguous resource. This clearly distinguishes it from siblings like openf1_laps or openf1_pit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly defines what data is returned and the context (per driving period), making it obvious when this tool is relevant. However, it does not explicitly mention alternatives or exclusion scenarios, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pandascore_match_oddsA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which cover safety and mutation traits. The description adds valuable behavioral context: potential 403 on free keys, the return shape being approximate and unverified, and advice to inspect the live payload. This goes well beyond the annotations and prepares the agent for real-world failure modes.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than strictly necessary but each sentence provides essential information: purpose, return shape, reliability caveats, and an example. The structure is front-loaded with the core purpose and then handles important caveats. Slight verbosity in the caveat section is justified given the unverified nature of the data.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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, which it does by providing an approximate shape. It also covers authentication, potential 403s, and the need to verify field names. For a single-parameter tool, this is fairly complete, though it could specify how to identify the correct match ID from pandascore_matches more explicitly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has one parameter (matchId) with a clear description, giving 100% schema coverage. The description adds a concrete example and references pandascore_matches, which reinforces the schema but does not introduce novel semantic meaning. Baseline 3 is appropriate since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's function: retrieving betting markets and prices for a single esports match. It uses a specific verb-plus-resource construction and distinguishes itself from sibling opendota tools by noting it provides data 'the part `opendota` cannot give you.' This makes the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives useful context: it is the go-to for esports match odds when opendota data is insufficient. It also warns about the paid add-on and auth key requirements, implying when the tool may not work. However, it does not explicitly state alternatives or when not to use it beyond the opendota comparison, which is a slight gap.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_labelsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds useful context: the return shape, the per-sport grouping, and the fact that no auth is needed. This is meaningful behavioral disclosure 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tight and front-loaded: purpose, example, return shape, and auth in two concise lines. Every sentence earns its place, and there is no filler or repetition of schema information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter dictionary lookup, the description is complete: it explains what is returned, the top-level array structure, per-sport grouping, and auth requirements. The absence of an output schema is adequately compensated by the explicit return shape in prose.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so the baseline is 4. The description correctly focuses on what the tool returns rather than parameters, and the example mapping adds a helpful touch even though no parameter documentation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('decodes') and names the resource ('per-sport market-label dictionary'), with a concrete example (moneyline → 'Match Odds'). This clearly identifies it as a label-lookup utility and distinguishes it from sibling tools that fetch matchups or market data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The purpose statement strongly implies when to use it: when you need human-readable labels for Pinnacle market keys. However, there is no explicit guidance about when not to use it or how it compares to related tools like pinnacle_enums or pinnacle_matchup_markets.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_league_matchups_liveA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish read-only, idempotent, and open-world behavior. The description additionally discloses the exact return shape, top-level array behavior, empty response behavior, and that no auth is needed, adding value 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: a one-line purpose statement, a concise return signature with empty semantics, and an auth note. Every sentence earns its place with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool with no output schema, the description provides all essential operational context: input provenance, output shape, empty behavior, and authentication status. There are no significant gaps given the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, leagueId, is fully described in the input schema with provenance and URL-path context, giving 100% schema coverage. The description adds only the 'one league' scope, so the schema carries the parameter-semantics burden and the description need not compensate further.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Live (in-play) matchups for one league (competition)', which clearly states the verb, resource, and scope. This distinguishes it from siblings like pinnacle_league_matchups (non-live) and pinnacle_sport_matchups_live (sport-wide rather than league-scoped).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly signals when to use this tool: when you need live/in-play matchups for a single league. It also explains the empty-array case ('empty when nothing live'), which gives practical context, though it does not explicitly name alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_matchup_relatedA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is known. The description adds value by providing the return format ('Returns: [{id, type, participants:[{name}], hasMarkets}]') and stating 'Auth: none needed', which are useful behavioral details 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: one sentence for the core purpose, plus a minimal return type and auth statement. Every word carries meaning, with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple lookup tool with one required parameter and no output schema in the structured data, the description provides enough context: it explains the relationship (same event's sub-matchups/alternative lines) and gives an inline return structure. This is complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%—the only parameter 'matchupId' is already well-described in the schema as 'Matchup id. Required — part of the URL path.' The description text does not add additional meaning for this parameter beyond what the schema provides, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Matchups related to one matchup' with elaboration as 'the same event's sub-matchups / alternative lines'. It identifies the specific resource (related matchups) and differentiates from sibling tools like pinnacle_matchup (single matchup) and pinnacle_matchup_markets (markets for a matchup).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: when you need matchups related to a given matchup within the same event, specifically sub-matchups or alternative lines. It does not explicitly name alternatives, but the relationship definition implies the use case and helps avoid using other matchup tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_competitionA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnly and idempotent behavior, so the description adds value by explicitly stating 'Auth: none needed' and the return shape '{id, code, name}'. It goes beyond what annotations provide without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: three short sentences covering purpose, return value, and authentication. Every sentence adds distinct value with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only getter with one parameter, the description fully covers the essential context: what it does, what it returns, and that no auth is needed. Annotations cover safety and idempotency, making this complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully documents the 'cid' parameter, including the example (8 = Premier League) and that it's required and part of the URL path. The description repeats this information without adding new semantic detail, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches one competition by id, with a specific example (8 = Premier League). This distinguishes it from sibling pl_competitions (plural), which presumably lists competitions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'One competition by id' implies usage for a single competition lookup, contrasting with plural alternatives. However, it does not explicitly mention when not to use it or name an alternative tool, leaving some implicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_player_infoA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it readOnly and idempotent. The description adds 'Auth: none needed' and explicitly lists the returned fields. It adds useful context without contradicting the annotations, though it doesn't mention potential edge cases 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, no filler. The main purpose is first, followed by return structure and auth note. Every word contributes useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward read-only endpoint with 3 fully documented parameters and no output schema, this description is complete: it states scope, lists all returned fields, and confirms auth requirements. It gives enough for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers all three parameters with descriptions, including examples for sid and cid. The description's 'scoped to a season' reinforces the sid parameter's meaning but adds no new parameter detail beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Player bio scoped to a season — team/shirt/dates as they were that season.' This clearly distinguishes the tool from siblings like pl_player or pl_player_basic, which lack the seasonal scoping.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly sets the context: this tool is for season-specific player bio data. While it doesn't explicitly name alternatives or say 'when not to use,' the scoping phrase provides clear guidance on when this tool is appropriate, differentiating it from season-agnostic player endpoints.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_competition_eventsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds value beyond annotations by disclosing the exact return shape ({key, name, nextPage, events:[...]}), the nextPage-based pagination behavior, and that no auth is needed—none of which appear in 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The purpose is front-loaded in a single line, followed by a compact return-shape line, a minimal JSON example, and a one-line auth note. There is no filler or redundancy—every element earns its place and the structure is highly scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema present, the description carries the burden of return-value disclosure and does so with a concrete structure, pagination semantics, and a worked example. Combined with rich annotations, full parameter documentation in the schema, and auth disclosure, the tool is fully specified for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and both parameters are already well documented: page is described as '1-based page; follow nextPage in the response' and competitionKey includes an example and its source from pointsbet_sport_competitions. The description's example JSON reinforces usage but adds little meaning beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening line 'Featured events for one competition (paged) with their insight/featured markets' uses a specific verb/resource pairing and clearly scopes to a single competition, distinguishing it from sport-level siblings like pointsbet_sport_featured_events. The mention of paging and the specific market types adds further precision beyond a generic listing statement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example ('AFL competition events, first page' with competitionKey 7523) and the schema note that competitionKey comes 'from pointsbet_sport_competitions' give clear contextual guidance on when and how to invoke the tool. However, no explicit alternatives or when-not-to-use exclusions are stated, so differentiation from pointsbet_sport_featured_events remains implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_eventA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral context: 'Auth: none needed' and the exact return shape, including nested markets and outcome structure. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lean and well-structured: a single opening line summarizing capability, a returns block with type shapes, and an auth note. No redundant phrasing or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (1 parameter, no output schema), and the description compensates by providing a detailed return structure. It covers purpose, input source, auth, and expected output, making it complete for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes eventKey with type, example, source, and requirement. The description does not add parameter-specific meaning beyond what the schema provides. With 100% schema coverage, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Full event detail' with an explicit list of contents (fixed-odds markets, selections, prices, SGM, team stats, insights). This distinguishes it from simpler list/search tools in the PointsBet family and other event tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context: to get comprehensive event data when you have an eventKey from any events feed. It doesn't explicitly name alternatives or exclusions, but the phrase 'Full event detail' and the requirement for an eventKey give clear context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_events_nextupA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds useful behavioral details beyond annotations: 'Auth: none needed' and 'ordered by start time', plus the exact return structure. This enriches the agent's understanding without contradicting any annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is remarkably concise: two short sentences that front-load the core purpose, then provide return structure and auth info. Every word earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one optional parameter and no output schema, the description covers all essential aspects: the scope (all codes), ordering, return fields, and authentication. It is complete enough for an agent to invoke and interpret the response correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, v2Limit, is fully documented in the input schema ('Max events to return.'), giving 100% schema coverage. The description does not add extra parameter context, so it meets the baseline but does not enhance it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Next-up sport events across all codes, ordered by start time (homepage feed).' This clearly differentiates it from sibling tools like pointsbet_event_search or pointsbet_sport_featured_events by emphasizing the cross-code, time-ordered homepage feed context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'homepage feed' phrase provides clear context for when to use this tool versus more specific alternatives, but it does not explicitly name alternatives or state exclusions. This is clear context without full when/when-not guidance, so it earns a 4.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_promo_codeA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the bar is lower. The description adds value by revealing the return shape ({info, image}) and explicitly stating 'Auth: none needed,' which are behavioral details not present in 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: one purpose sentence, a return type line, an example block, and an auth note. Every line serves a distinct purpose with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema, it includes the input example, return type, and auth requirement. This is sufficient for an agent to select and invoke the tool correctly without needing additional information.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and already provides an example ('WELCOME') and states the parameter is part of the URL path. The tool description merely repeats the same example in its own format, adding no new semantic information. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action: 'Sign-up splash content (info text + hero image) for a named promo code.' It identifies the resource (named promo code) and distinguishes this tool from siblings like pointsbet_promotions or pointsbet_content_call by scoping it to sign-up splash content.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: it is for a named promo code, and the example shows a direct invocation. It does not explicitly mention when not to use it or name alternatives, so it is a clear context without exclusions rather than full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_racing_hourly_quaddieA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, setting a low bar. The description adds value by disclosing 'Auth: none needed' and specifying the exact return structure with fields like date, hour, advertisedHourUtc, and races. This goes beyond the annotations and provides useful behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise: a one-line summary immediately followed by a structured return type and an auth note. Every sentence provides necessary information with no fluff or repetition. The most critical info (what it returns, auth) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no parameters and no output schema, the description includes a full return type definition, making the tool's output completely predictable. The 'Auth: none needed' addresses the main access concern. For a simple read-only schedule tool, nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the input schema is trivially covered. The baseline for no parameters is 4, and the description adds no unnecessary parameter complexity. The return format description compensates for the absence of output schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Hourly Quaddie schedule — the four-leg quaddie races grouped by hour' clearly states the tool's verb (schedule) and resource (hourly quaddie races). It distinguishes itself from sibling racing tools like pointsbet_racing_tips and pointsbet_racing_form by specifying the exact focus on hourly quaddie groupings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving hourly quaddie scheduling information but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The context is clear enough for a simple read-only schedule, but the absence of direct usage comparison to siblings leaves room for ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_racing_insightsA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnly, openWorld, idempotent), the description discloses the 204 No Content behavior when insights are not yet published, the exact return shape, and that no authentication is needed. This adds meaningful behavioral context that annotations do not capture.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, using three short labeled sections. It front-loads the primary purpose and avoids any redundant information, making every sentence informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one param, no output schema), the description fully covers the essential use case, including response format and edge cases like 204. The annotations cover safety, so no additional context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for the single parameter (raceId) with a clear description. The tool description adds no additional semantic detail for the parameter, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides editorial form insights for a single race, using a specific verb+resource structure. It distinguishes itself from siblings like pointsbet_racing_tips (tips) and pointsbet_racing_form (form data) by specifying 'editorial insights' and 'one race'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description mentions that content may be empty before publication, implying a timing consideration, but it does not explicitly state when to use this tool versus alternatives like pointsbet_racing_tips or pointsbet_racing_form. Usage context is implied but lacks explicit guidance or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_racing_meetingA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds 'Auth: none needed' and specifies the exact return shape, which is critical since no output schema exists. It adds useful context beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short sentences cover purpose, return format, and auth. Every sentence provides distinct value with no redundancy. Front-loaded with the essential purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter read-only tool, the description includes the return structure (compensating for missing output schema) and auth requirements. Annotations cover safety/idempotency. No significant gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and already explains meetingId includes an example and source. The description does not add additional parameter semantics, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches a single race meeting by ID and lists what it returns (venue, conditions, races). The singular 'One race meeting by id' distinguishes it from the sibling pointsbet_racing_meetings (plural). Specific verb+resource+scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Implied usage: use this when you have a meetingId and need its details/races. The 'by id' phrasing contrasts with the plural list tool, providing clear context. However, it does not explicitly name an alternative or state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_racing_srmA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover readOnly, openWorld, and idempotent. The description adds valuable context: returns availability only when open ('availability + legs/prices when open'), shows the return fields, and notes 'Auth: none needed.' This goes beyond the annotations and adds operational detail without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-sentence purpose, a return format line, an auth line, and an alternatives line. All sentences earn their place and critical information is front-loaded. No redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the absence of an output schema, the description lists the return fields and explains the conditional availability. It covers auth, scope, and sibling relationships. For a simple one-parameter read-only tool, this is complete enough for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description covers the only parameter (raceId) with 'Race id. Required — part of the URL path.' The tool description does not add extra meaning for the parameter beyond implying it's tied to the specific race. Given 100% schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Same Race Multi (SRM) market for one race (availability + legs/prices when open).' This uses a specific resource (SRM market) and scope (one race), and includes the return structure. It distinguishes itself from siblings like pointsbet_racing_races (multiple races) and sportsbet_racing_popular_srms by explicitly noting it's for a single race and mentioning it can answer for those siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it's for one race and requires no auth. It also names alternative tools ('Also answers this: entain_graphql_call, sportsbet_racing_popular_srms'), which helps an agent consider substitution. However, it doesn't explicitly state when NOT to use it or direct to alternatives for multiple races, so it's not a perfect 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• polymarket_series_listA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (read-only, idempotent), the description adds valuable behavioral context: 'Auth: none needed' and a concrete return shape with field names. This tells the agent exactly what to expect from the call, which annotations don't cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: one sentence for the concept, one for the return format, and one for authentication. Every sentence earns its place without redundant filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with thorough schema documentation and clear annotations, this description is complete. It explains the return array structure, auth requirements, and the tool's position in the hierarchy, leaving no major gaps for an agent to misuse it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so all six parameters are well documented in the input schema itself. The description adds no additional parameter-specific meaning, matching the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a 'Series catalogue' that lists series, and explicitly defines series in the context of the Gamma hierarchy (series → events → markets). This distinguishes it from sibling tools like polymarket_events or polymarket_markets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear context that this lists series at the top of the hierarchy, making it obvious when to use it versus lower-level tools. It doesn't explicitly name alternatives like polymarket_series, but the hierarchy description implies the usage boundary.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• seriea_match_lineupsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety is covered. The description adds valuable behavioral context by detailing the exact return structure (matchId, pitchSize, home/away with fielded players and events) and explicitly stating 'Auth: none needed.' This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-line summary of what is returned, followed by the explicit return object shape. Every sentence provides useful information, with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even without an output schema, the description fully enumerates the return fields, giving the agent everything needed to interpret the response. It also covers prerequisites, auth requirements, and scoping. This is complete for a lookup tool of moderate complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% parameter description coverage, so the schema already documents all three parameters. The description's mention of 'Discover the matchId from seriea_matches' echoes the schema's own guidance, adding no new meaning. Baseline of 3 is appropriate when schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states exactly what the tool does: fetches lineups for one match, with per-side details like formation, fielded XI, bench, and staff. It also distinguishes itself by referencing the prerequisite discovery of matchId from seriea_matches, which differentiates it from other match-lineup tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly indicates this is for a single match and instructs the user to obtain the matchId from seriea_matches first. While it doesn't explicitly list exclusions or alternatives, the context of 'one match' and the discovery step provides sufficient usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• seriea_seasonsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds useful behavioral context beyond annotations: 'The Serie A competition id is baked in', 'Auth: none needed', and the exact return shape including the seasonName format. This gives the agent extra confidence and practical knowledge without conflicting 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded, immediately stating the resource and scope. The return format is condensed into a single line, and the auth note is minimal. Every sentence adds value and there is no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only listing tool with one optional parameter and no output schema, the description is complete. It covers what is returned, how to use the result, that no auth is needed, and how the competition ID is embedded. No important information is missing for the agent to invoke and use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents 'locale' as 'Label language' with a default of 'en-GB', and schema coverage is 100%. The tool description does not add any additional meaning about the parameter—it never mentions locale or how it affects the output. With full schema coverage, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: returns all 41 Serie A seasons with seasonId and seasonName. It explicitly positions itself as the starting point for getting a seasonId before drilling into standings/teams/players/matches, which distinguishes it from sibling tools like seriea_standings and seriea_season. The scope is precise and the verb is implied by 'All 41 Serie A seasons'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: 'start here to get a seasonId, then drill into standings/teams/players/matches'. It tells the agent when to use this tool and what to do next. It does not explicitly state when not to use it or mention alternatives like seriea_season, but the 'start here' guidance is clear enough for a simple listing tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• seriea_teamsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly/openWorld/idempotent, and the description adds the exact return structure and authentication requirement (Auth: none needed). It also clarifies the season-scoped nature, going beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the core purpose, followed by a compact return structure and auth note. Every sentence adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read tool with two parameters and no output schema, the description provides the return shape, scope, and auth, making it self-sufficient. The absence of explicit alternatives is minor given the clarity of the tool's purpose.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters have schema descriptions (100% coverage), so the baseline is 3. The description does not add material meaning beyond the schema; it merely mentions seasonId comes from seriea_seasons, which is already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns the 20 teams in a season with identity and imagery, and explicitly notes it is season-scoped. This specific verb+resource combination differentiates it from other Serie A tools like standings or players.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by stating season-scoped scope and showing the return shape, implying seasonId comes from seriea_seasons as noted in the schema. However, it does not explicitly state when to prefer this over alternative team-listing tools or provide exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• seriea_team_statsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint annotation, the description discloses the return structure (teams, stats, pagination), auth requirement (none), and the category limitation. It does not contradict annotations and gives a clear picture of output shape.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and information-dense: the first sentence covers purpose and content, the second explains category behavior, and the third provides return format and auth. No fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 specifies the return structure including nested fields and pagination, plus auth and category restrictions. This is sufficient for an agent to invoke the tool confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for all four parameters (100% coverage), so the description adds little beyond a cross-reference to the player category rule. This meets the high-coverage baseline without adding significant new meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description precisely states the tool's function: a 'Team stat leaderboard for a season' with all 20 teams and full Opta stats. This clearly distinguishes it from siblings like seriea_standings, seriea_teams, and seriea_players, making its purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it is for a season, requires seasonId (from seriea_seasons), and the category rule is explained. It does not explicitly name alternatives or say 'when not to use', but the tool name and content make the use case evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sleeper_league_draftsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is known. The description adds valuable context by disclosing the exact return shape, the fact that no auth is needed, and the one-per-season nuance for dynasty leagues. This goes beyond what annotations alone provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise yet information-dense: a clear purpose, a compact return specification, a minimal example, and an auth note. Every sentence earns its place, and key details are front-loaded. There is no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only list tool with a single parameter and no output schema, the description is highly complete. It provides the return structure, an example call, auth requirements, and domain-specific context about dynasty leagues. The agent can invoke the tool correctly and interpret results without needing additional information.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, league_id, is fully described in the schema with 'League id. Required — part of the URL path.' The description adds a concrete example value and explains it is the league whose drafts are returned, but does not add significant semantic detail beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that this tool retrieves the drafts belonging to a league, with the return format giving exact fields such as draft_id, league_id, season, and type. It distinguishes from sibling tools like sleeper_draft and sleeper_draft_picks by focusing on the collection of drafts for a league, and the dynasty note adds specificity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: call this when you need the list of drafts for a given league, and the dynasty league note clarifies when to expect one per season. It does not explicitly mention alternative tools, but the context and example provide clear when-to-use guidance. No exclusions or when-not-to-use cases are stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportmonks_playersA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/openWorld/idempotent annotations, the description discloses that the response shape is unverified from vendor docs, that the provider key is not held, and that the field names should be treated as approximate. It also explains the statistics inclusion mechanism and numeric type_id. This is valuable behavioral context that goes well beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but mostly relevant: it front-loads the purpose, then provides the return shape, a caveat about unverified data, an example, and auth info. The capitalized 'SHAPE FROM VENDOR DOCS' and 'Example: Players on your plan' add some noise, but overall each sentence contributes useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with three optional parameters and no output schema, the description covers the essential context: what data is returned, how to request statistics, the unverified nature of the response shape, and authentication needs. The pagination field in the return shape plus explicit parameter descriptions make this adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all three parameters with descriptions, so the baseline is 3. The description adds extra meaning by explaining how the include parameter works ('statistics.details'), providing an example value, and noting the numeric type_id keying. This gives the agent a better mental model than the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as players from SportMonks and notes the optional season statistics via include. Although it lacks an explicit verb like 'get' or 'list', the phrase 'Players, with season statistics when included' and the return shape make the purpose unambiguous. It distinguishes itself from sibling tools by naming SportMonks and the statistics capability.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it returns players and season statistics only when the include parameter is specified. It gives a concrete example of using the include parameter and notes authentication requirements. It does not explicitly mention alternative tools or exclusions, but the context is sufficient for an agent to decide when to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_match_previewA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the return format ({preview:{title, body, videoUrl}}) and that auth is not required. Annotations already state readOnlyHint, openWorldHint, and idempotentHint, so the description adds useful context without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences with a clear return format and auth note. Every word earns its place, with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only preview tool with no output schema, the description fully explains the return structure and authentication requirements. All parameters are documented in the schema, making the tool ready to use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers 100% of parameters with inline descriptions. The tool description itself adds no additional parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states it provides an 'Editorial match preview (text + video) for one sport event' with a specific return structure. This clearly identifies the tool's function and distinguishes it from siblings like sportsbet_race_preview or odds/market tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly indicates it is for a single sport event and that no authentication is needed, but does not explicitly mention when not to use it or provide alternatives. The context is clear enough but lacks explicit exclusions or alternative tool references.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_racing_event_meetingA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to state safety. The description adds 'Auth: none needed,' which is a useful behavioral detail, and discloses that the response includes meeting and races. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences: the purpose, the return shape, and the auth requirement. It is front-loaded with the main purpose and contains no filler or redundant details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description provides the return structure ({meeting:{competitionId, name}, races:[{eventId, raceNumber}]}), which is essential for an agent to use the result. Along with the single parameter and annotations, this covers all necessary context for this simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully describes the single parameter eventId as 'Racing event id. Required — part of the URL path.' The tool description does not add further meaning to the parameter. With 100% schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: 'Meeting context for one racing event (parent meeting + sibling races).' It identifies the resource (racing event) and the scope (meeting and sibling races), and also provides the return shape, which distinguishes it from sibling racing tools like sportsbet_racecard or sportsbet_racing_allracing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a clear use case: given a racing eventId, retrieve the meeting context and sibling races. It does not explicitly name alternative tools or provide when-not-to-use guidance, but the narrow scope (one racing event) gives sufficient context for selecting this tool among similar racing tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• squiggle_sourcesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints, so the safety profile is known. The description adds valuable behavioral context beyond this: the return structure ({sources:[{id, name, url, icon}]}), the semantic meaning of 'id' as a filter, an example query, and confirmation that no authentication is needed. This is beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and information-dense. It front-loads the primary purpose, then provides return format, an example, and auth status. There is no wasted prose—every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with no output schema, the description is fully complete: it specifies the purpose, the exact return structure, the relationship to sibling tools, an example, and auth requirements. Given the low complexity and rich annotations, no further context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, with clear meaning for both parameters: 'q' (leave as-is) and 'year' (season filter). The description adds an example use of 'q' with the fixed value 'sources', reinforcing the schema, but it does not add further semantic detail beyond the schema. Since schema covers all parameters, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: listing the forecasting models Squiggle tracks and providing sourceid values used by tip tools. It uses a specific verb ('call this first to learn') and directly distinguishes itself from related sibling tools like squiggle_tips and squiggle_ladder by explaining the filtering relationship.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs when to use the tool: 'call this first to learn the sourceid values the tip tools filter on.' This provides clear context for usage and implies an ordering relative to squiggle_tips and squiggle_ladder. It doesn't explicitly list when not to use it, but the guidance is sufficiently clear for a simple lookup tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• supercoach_teamsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, open-world, and idempotent. The description goes beyond by stating the return shape ('array of {id, name, abbrev, ...}'), explicit 'Auth: none needed', and an example request. This adds meaningful behavioral context without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: five short sentences plus a JSON example. Each part serves a purpose—purpose, contents, join hint, return shape, example, auth—with no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with no output schema, the description provides purpose, return shape, auth, supported sports, and an example. It is complete for selecting and invoking the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with detailed descriptions for all three parameters (mode, year, sport). The description's example and team counts add marginal context, but the schema already explains the parameters thoroughly, so the description does not significantly compensate or add beyond the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns a club/team catalogue for a specific game and season, listing counts per sport and fields (id, name, abbrev). It distinguishes itself from player tools by explicitly noting the join from supercoach_players, and is distinct from generic team list tools by its SuperCoach-specific scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context that this is for fetching SuperCoach team catalogues, with a concrete use case: 'Join team_id from supercoach_players back to here.' It does not explicitly name alternatives or when-not-to-use conditions, but the context is sufficient for selection among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_search_recentA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as read-only, idempotent, and open-world, so safety is covered. The description adds valuable context beyond annotations: it requires an API key (X_BEARER_TOKEN), limits the search to the last 7 days, and outlines the response structure, which significantly helps an agent anticipate behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: one sentence states the purpose, a second block reveals the return format, and a final line covers authentication. Every sentence adds new information without redundancy, making it easy to scan and apply.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having 10 parameters and no output schema, the description compensates well by explicitly showing the expected response structure (data, includes, meta), outlining the auth requirement, and giving a query example. This provides sufficient context for an agent to invoke the tool correctly and interpret results, even without an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all 10 parameters. The description provides a helpful example query and confirms the 7-day window, but it does not add semantic detail beyond that; the schema already offers thorough parameter descriptions. Baseline 3 is appropriate because most parameter meaning comes from the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description specifies a clear action ('Search posts') with a defined scope ('from the last 7 days') and gives a concrete query example. This distinguishes it from sibling Twitter tools that fetch individual tweets, user timelines, or counts, making the tool's unique purpose explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use it: when searching recent posts with query operators. It does not explicitly name alternative tools or state when not to use it, but the context is strong enough that an agent could infer appropriate usage, especially with the example query and time bound.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wta_rankingsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds useful behavioral details about the response being a bare array and that no authentication is needed. It does not contradict any annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with purpose, usage, example, and auth. However, the return row structure is repeated (once in the first sentence and again in the 'Returns:' line), adding slight redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with 4 parameters and no output schema, the description covers the return format, required parameter agreement, pagination, example, and auth. It is sufficiently complete for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameters are well-documented. The description adds value by explicitly stating the required type/metric agreement and providing a sample JSON request for the top 100 singles, reinforcing the schema's enum constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies this tool as returning WTA rankings with a specific row structure. It distinguishes itself from sibling tools like wta_players by focusing on ranking data and explicitly noting the return format (bare array vs envelope). The purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on how to use the tool: it requires type and metric that must agree, and it gives a concrete example for fetching the top 100 singles. However, it does not explicitly state when to use this versus alternative ranking tools or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_gameA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, which cover the safety profile. The description adds valuable context: it explicitly warns that the return shape is from vendor docs and has NOT been verified against a live response, and instructs to inspect actual payloads. It also discloses authentication requirements (YAHOO_CLIENT_ID etc.), which is beyond what annotations provide. This is strong behavioral transparency given the annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: the first line defines the purpose, followed by the return shape, then example, then auth note. The shape note and auth note are useful and earn their place. Slight verbosity in the dream shape note, but overall tight and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple (metadata lookup) and has a clear input schema, annotations, and no output schema. The description explains the return shape (as a note pending verification), provides an example, and discloses auth requirements. Given the tool's simplicity and existing structured fields, the description is comprehensive enough. The only gap is not explaining pagination or multiple game responses, but that's minor for a metadata-only call.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (both format and gameKey are described in the schema). The description adds meaning to gameKey by listing acceptable values ('nfl', 'nba', 'mlb', 'nhl', or numeric id like '449') and noting it's part of the URL path. The description also shows a JSON example with 'gameKey'. Since the schema already covers parameters well, the description's additional usage details push it slightly above baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Game metadata for a sport-season' and lists the specific fields returned (season year, whether it is over, and the game_key). It explicitly mentions 'the game_key other calls need', which distinguishes it from sibling tools like yahoo_my_games or yahoo_league that serve different purposes. The description also includes an example and return shape, making it highly clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an example usage ('Current NFL season' with 'gameKey': 'nfl') and notes that the game_key is needed by other calls, implying this is a prerequisite step. However, it doesn't explicitly state when NOT to use this tool or suggest alternatives (siblings like yahoo_my_games might be used for user-specific data). Still, the context is reasonably clear for the primary use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_game_roster_positionsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and idempotentHint=true, which are partly redundant with the description's read-only framing. The description adds valuable context: the response shape is from vendor docs and NOT verified against live responses—an important caveat. It also explains how to interpret the shape, which supplements the annotations. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured. It starts with the core purpose, then gives the response shape, then a caveat, then an example. All sentences add value. The example could be clearer (it shows a request-like object without clarifying it's an example), but overall it's efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple (2 params, no nested objects), and the description covers purpose, usage, auth, response shape, and unverified status. The output schema is absent, but the description provides the return shape explicitly, compensating. The caveat about unverified shape is particularly valuable for an agent. Missing: no info on error cases, but that's beyond expectation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (format and gameKey both have descriptions), so the baseline is 3. The description adds semantics for gameKey via the NFL example and explains how the response is used, which goes beyond the schema. It doesn't add much on format, but that is trivial. The response shape explanation adds value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: 'The roster positions a game defines (QB, RB, FLEX, BN, IR…)'. It specifies the resource (roster positions) and the purpose (needed to build a valid lineup write). It also distinguishes this from sibling tools like yahoo_game or yahoo_team_roster by focusing on the game-level roster positions, not team rosters or game metadata.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when building a valid lineup write, and provides an example call for NFL. It doesn't explicitly state when not to use it or alternatives, but the context is fairly clear: this tool is for retrieving game-level position definitions. The auth note clarifies prerequisites. Could be improved with explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_cfs_callA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds valuable behavioral context beyond the annotations: the automatic minting of the anonymous x-media-mis-token, the pattern of provider IDs (CD_M*/CD_R*/...), and the need to map integer IDs. It also explicitly states 'Auth: none needed,' aligning with the readOnlyHint and idempotentHint annotations without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose. It uses four short sentences to convey scope, token behavior, ID mapping, and reference to the operations list. The 'Returns:' and 'Auth:' lines are terse but informative, with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a generic call tool with no output schema, the description covers the essentials: what it calls, how to discover operations, how to handle path params, and the token requirement. It stops short of explaining error cases or return structure beyond 'JSON object,' but given the openWorldHint and reference to the catalogue, it is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  While the schema already documents the three parameters (operation, path_params, query_params) with 100% coverage, the description enriches them by explaining that operation names come from the catalogue resource, path_params use provider IDs, and query_params are documented in the catalogue. This adds practical meaning beyond the dry schema text.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Call any of the AFL CFS premium operations' with a specific URL base. It distinguishes itself from sibling tools by being a generic call tool for premium operations, while siblings like afl_competitions_list or afl_match_get target specific AFL resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides concrete guidance: 'Read afl://cfs/operations for the full op list' and explains how to map integer IDs via idmap endpoints. However, it does not explicitly say when to prefer this tool over the dedicated AFL sibling tools, though the 'premium operations' scope implies it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_content_text_listA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context beyond this by detailing the return structure, noting auth is not required, and giving an example request. Such details help the agent understand expected behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and concise: purpose, return format, example, and auth note. Each sentence contributes meaningful information without redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 specifying the return shape. It covers purpose, example, and auth. However, it could further clarify pagination semantics (e.g., offset/limit vs page/pageSize) beyond the schema, though the schema already documents this. Overall, it is adequate for a list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, providing baseline. The description adds value by illustrating how to use referenceExpression and tagExpression in a realistic example, clarifying which parameters are primary for filtering. This goes beyond the schema's per-parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists text articles (news) with reference/tag filters. It distinguishes itself from siblings like afl_content_video_list (video) and afl_content_text_get (single item retrieval) by specifying the resource type and filter options.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear context for use (listing news articles with filters) and provides a concrete example with AFL/AFLW news. However, it does not explicitly name alternatives or state when not to use this tool, which would be needed for a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_players_idmapA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already disclose readOnlyHint, openWorldHint, and idempotentHint, so the description's additional details—payload size (~98 KB), auth requirement (none), and the exact return structure—are valuable. This goes beyond the annotations and helps the agent anticipate a potentially large response.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the main purpose, followed by concise Returns and Auth lines. Every sentence serves a purpose without unnecessary detail, making it easy to scan and understand.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with no parameters and no output schema, the description provides purpose, scale, return format, and auth. It is nearly complete, though it could mention whether the map is exhaustive or if there are any caveats about coverage of historical players. The 'every player' wording implies completeness, so this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so schema coverage is 100% vacuously. The description adds meaning by specifying the output shape (`{entityType:'player', idMapResponse:{ids:{...}}}`), which is useful for parsing the response, even though no parameter semantics are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool maps every player providerId (CD_I*) to its integer id, using a specific verb ('Map') and resource ('every player providerId'). This distinguishes it from sibling tools like afl_players_list or afl_player_get, which likely provide player details rather than an ID mapping. The scale (~98 KB, 17k+) also adds precise context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for translating CD_I* provider IDs to integer IDs, which is clear from the context of sibling idmap tools (afl_teams_idmap, afl_matches_idmap). However, it does not explicitly state when to prefer this over alternatives or when not to use it, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_football_leaguesA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/idempotent annotations, the description discloses the need for an API key, warns that the returned shape is unverified and approximate, and explains the significance of coverage. It also notes plan restrictions via the schema, adding valuable behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is efficiently structured: purpose, return shape, caveat, example, auth. Every section adds necessary information without verbosity. The shape block is long but essential given no output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list tool without an output schema, the description covers the return shape, coverage guidance, example usage, and auth requirements. It lacks pagination or rate-limit details, but these are not critical for this read-only discovery tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the 4 parameters already have clear meanings. The description adds a concrete example with country and mentions 'FREE PLANS are restricted to a few older seasons' in the schema, but doesn't provide additional parameter-level semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Football leagues and cups worldwide, with the seasons available on your plan.' This specifies the resource (leagues/cups) and scope, and distinguishes it from sibling tools like fixtures, standings, and teams by noting that coverage tells you which tools will return data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage as a discovery tool: 'coverage matters: it tells you which of the tools below will actually return anything for that league.' This provides context for when to use it before calling other apisports tools. However, it doesn't explicitly state exclusions or name alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_football_playersA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds substantial value beyond these: it specifies the auth requirement (API_SPORTS_KEY), warns that the documented response shape is unverified and approximate, and explains that `statistics` is a list with one entry per competition. This is excellent behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is efficiently structured: a one-sentence purpose, a detailed return shape, a caveat about unverified vendor documentation, a concrete example, and an auth note. Every sentence earns its place, and the critical caveat is clearly highlighted. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description provides a comprehensive return shape including paging, a clear explanation of repeated entries, an example, and auth requirements. For a 6-parameter tool, this is more than sufficient context for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameters with individual descriptions, so the baseline is 3. The description adds practical value by reinforcing that `season` is required and by presenting a concrete example (team:42, season:2023) that demonstrates how the parameters are used together. This lifts it above baseline but doesn't add deep semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides 'Player season statistics for a team or league,' identifying the resource and scope. It distinguishes itself from sibling tools like apisports_football_teams (team info) and apisports_football_fixtures (match data) by focusing on player stats. A minor deduction for lacking an explicit verb like 'get' or 'list', though 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context on when to use the tool: when player season statistics are needed, filtered by team or league. It explicitly notes that `season` is required and provides a concrete example. It does not explicitly mention exclusions or alternatives, but the sibling tool names make the differentiation obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_football_predictionsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable context: it requires an API key in API_SPORTS_KEY, warns the response shape is 'from the vendor's documentation and has NOT been verified', and notes that 'percent values are STRINGS with a % sign'. These disclosures go beyond annotations and alert the agent to data reliability and formatting nuances.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a clear one-line summary, followed by a detailed return shape that is necessary because no output schema exists. It includes a caveat about the unverified shape, an example, an auth note, and comparison guidance in a logical order. The return-shape block is long but each part serves a purpose, making the overall structure effective.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description compensates with a full vendor-documented response shape and highlights important caveats (unverified shape, percent-as-string, auth requirement). It also provides guidance on how the output should be compared with squiggle tools. For a simple one-parameter read-only tool, this is highly complete and covers the main complexities.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage for the single 'fixture' parameter, which is described as 'Fixture id'. The description adds an example value (1035037) but does not explain how to obtain fixture ids or interpret them. Since the schema already documents the parameter, the description provides minimal additional semantic value, keeping it at baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns 'the vendor's own model prediction for a fixture, with the comparison data behind it' and lists the detailed response structure (winner, advice, percent, comparison, h2h). It distinguishes itself from market odds by noting it is 'a vendor model, not a market price', differentiating it from sibling tools like apisports_football_odds.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit context for comparison: 'compare it against squiggle-style model output, not against a bookmaker's line', which tells when to use this tool versus market-price tools. It also notes 'Also answers this: squiggle_tips, squiggle_ladder', offering alternative query paths. However, it does not explicitly explain when to prefer this over other apisports tools or provide exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• balldontlie_nba_statsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds substantial context beyond that: the full response shape with field names, the specific gotcha that `min` is a 'MM:SS' string not a number, an honest warning that the shape is unverified vendor documentation and should be inspected against a live payload, and the auth requirement for BALLDONTLIE_API_KEY. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the purpose, followed by a dense but useful return-shape block, a crucial unverified-data caveat, an example, and an auth note. It is longer than minimal descriptions, but every section earns its place given the lack of an output schema and the need to warn about payload reliability.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 burden of explaining return values: it provides a detailed data shape, explicitly flags the unverified nature of that shape, covers the min field type quirk, gives an example invocation, and states auth requirements. This is complete for a read-only data-fetching tool with a well-documented schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with each of the 6 parameters already described (dates, cursor, seasons, game_ids, per_page, player_ids). The description adds marginal value via the example showing player_ids and seasons used together and the return-shape note linking cursor to meta.next_cursor, but the schema carries the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Per-player, per-game NBA box-score lines' — a specific resource (NBA box-score lines) with clear per-player/per-game scoping. This distinguishes it from sibling balldontlie tools like balldontlie_nba_games, balldontlie_nba_players, balldontlie_nba_season_averages, and balldontlie_nba_standings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for use via the purpose statement and a concrete example query ({"player_ids": ["115"], "seasons": ["2023"]}), which implicitly shows how to filter for a player's game lines. However, it does not explicitly name alternatives or state when not to use this tool versus sibling balldontlie tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• chesscom_leaderboardsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context beyond this: the response size warning (~290 KB) and the exact return structure, which helps the agent anticipate the payload. No contradictions 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the purpose. The Returns block is a useful structured addition, and the auth note is brief. However, the 'Example: All leaderboards' line adds minimal value and could be considered slightly redundant, though it is not harmful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only tool with no output schema, the description is highly complete. It covers purpose, categories covered, return structure, response size, and authentication. The only minor gap is that the return structure is fully spelled out only for live_blitz, with ellipses for other categories, but the pattern is clearly implied.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description does not need to explain parameter semantics. The schema coverage is vacuously 100%. The description correctly omits parameter details, earning the baseline score of 4 for no parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as providing Chess.com's leaderboards for every category, listing specific categories like live blitz, bullet, rapid, daily, variants, and tactics. The Returns section further confirms it retrieves these leaderboards. This distinguishes it from sibling chess tools focused on individual players, stats, or archives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: it returns all leaderboards with no parameters. It warns about the large response size (~290 KB) and notes that no authentication is needed. It does not explicitly name alternatives, but for a zero-parameter retrieval tool, the usage scenario is obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketaustralia_standingsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds value by specifying the exact return structure (standings list with fields) and the behavior for competitions without a points table (empty). It also states that no auth is needed, which is consistent with the annotations and adds practical context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is remarkably concise: two short paragraphs that define the tool's purpose, note the required parameter, list the return fields, and state auth requirements. Every sentence contributes information without redundancy, and the structure is front-loaded and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity and the presence of rich annotations and a full schema, the description covers all essentials: what it returns (including the responseError field), the required parameter, and a caveat about empty results. It does not explain ordering or pagination, but those are not critical for a simple read-only ladder tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 goes beyond by reiterating the necessity of competitionId and explains the empty-result case for competitions lacking a points table, which adds behavioral meaning to the parameter. The source of the ID is also mentioned, though it is already present in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as retrieving a competition ladder with per-team statistics like played/won/lost, points, and net run rate. It specifies the resource (Cricket Australia standings) and distinguishes itself from sibling standings tools by naming the sport and the key requirement of a competitionId.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use it for Cricket Australia competition standings, and notes that competitionId is required (with the caveat that competitions without a points table may return empty). It does not explicitly mention alternative tools for other sports, but the context is unmistakable given the tool name and the pointer to the competitions tool for obtaining the ID.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketdata_current_matchesA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/openWorld/idempotent annotations, the description discloses the return shape, explicitly warns that the shape is unverified and from vendor docs, instructs the agent to inspect actual payloads, and states the auth requirement (CRICKETDATA_API_KEY). This is valuable behavioral context that annotations alone do not provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with purpose, then provides the return shape, a critical caveat, an example, and auth info. It is somewhat long due to the embedded JSON shape, but each element earns its place. The 'Example: Live and upcoming matches' line is slightly redundant with the first sentence, preventing a perfect score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 covers the return payload shape, notes field abbreviations (r/w/o), warns about reliability, and mentions auth. It is complete and self-sufficient for an agent to invoke the tool and handle its response appropriately.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter (offset) is fully described in the schema at 100% coverage ('Page offset (25 per page)'), so the description does not need to add much. It adds no new semantic detail about the parameter itself, matching the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: returns matches in progress or starting soon with live scores. The name and first line together distinguish this from sibling cricketdata_matches, which likely covers all matches. The scope is specific and actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The first sentence gives a clear temporal context for when to use this tool ('in progress or starting soon'), and the example 'Live and upcoming matches' reinforces this. However, no explicit alternatives or when-not-to-use guidance is provided, though the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketdata_series_infoA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the readOnly/idempotent/openWorld annotations by disclosing that the return shape is unverified from vendor docs and that the agent must inspect the actual payload before relying on field names. It also explicitly mentions the authentication requirement, adding significant behavioral transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is detailed but each section (return shape, caveat, example, auth) is essential. It's not bloated, and the structure is clear with returns, notes, and example separated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the single parameter and no output schema, the description provides a thorough overview: return shape, unverified caveat, example, and auth. The warning about verifying the actual payload is crucial for an agent to use it reliably.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes the single parameter (id) with source context. The description adds a small example of the JSON payload, but this is redundant with the schema's 100% coverage. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this retrieves a single series with its full match list, using a specific verb and resource scope. It distinguishes from siblings by explicitly saying 'One series' rather than a list tool like cricketdata_series.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies this is for when you have a specific series id and need that series' details and matches. It doesn't explicitly name alternative tools for lists of series or matches, but the context is clear and no exclusions are stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dabble_fixture_detailsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/openWorld/idempotent annotations, the description discloses the response size, the complete return structure, the engine-derived product classification logic (with precise rules based on capability flags and resultingType), and that no auth is needed. It also warns against blending pickem multipliers into fixed-odds calculations, adding valuable behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long and dense, but it is well-structured: the first sentence states the core purpose, and each subsequent paragraph addresses a specific aspect (size, product derivation, return shape, usage caution). It is not padded, but the sheer length prevents a perfect score for conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and only one parameter, the description fully compensates by specifying the exact return shape, the product classification rules, size warnings, and appropriate usage cautions. It gives an agent everything needed to correctly invoke and interpret the tool's results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage for fixtureId, including its source (dabble_competition_fixtures) and that it is required. The description repeats this source but adds no new parameter-specific semantics, so it meets the baseline of 3 without exceeding it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'The FULL book for one fixture' and explicitly enumerates the contents: every market, selections + prices, marketGroups, and Pick'em playerProps. This clearly states the tool's function (returns detailed fixture data) and distinguishes it from siblings like dabble_competition_fixtures, which likely only list fixtures.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description tells the user that fixtureId comes from dabble_competition_fixtures and warns that the response is LARGE (~1 MB+), advising to fetch one fixture at a time. This provides clear usage context, but it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espn_cdn_callA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint and idempotentHint annotations, the description discloses caching behavior, the default xhr=1 query parameter, league coverage limitations, and the error behavior for guessing operations. This adds substantial operational context without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence in the description earns its place: source, data types, slug rules, coverage limits, operation discovery, and auth. The information is front-loaded and the Returns/Auth lines are terse yet useful, making this a well-structured and efficient description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the generic gateway nature with no output schema and three parameters, the description covers essential knowledge: endpoint source, slug semantics, default query parameter, how to discover operations, and auth. It also notes a key error-recovery behavior (guessing an operation returns alternatives), making it complete for first-time invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is met. The description adds practical meaning beyond the schema by giving concrete slug examples (nfl, eng.1), clarifying that path_params uses the league slug, and noting the automatic xhr=1 for query_params. These details are more actionable than the schema's generic catalogue references.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a gateway to the ESPN CDN core live feed, listing the data types (scoreboard/game/boxscore/playbyplay JSON). It distinguishes itself from siblings by emphasizing the CDN source and providing league-slug examples, though the verb 'gateway' is slightly generic.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit usage context: path slug is the league not the sport, soccer uses competition slugs, no NHL coverage, and gameId comes from the scoreboard op. It also directs users to browse espn://cdn/operations. It doesn't name alternative sibling tools, but the guidance is sufficient for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_player_infoA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description does not contradict them. It adds useful behavioral context by disclosing the auth requirements ('works without a key; ESPN_FANTASY_COOKIE unlocks more') and by detailing the return structure, which is absent from an output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average but well-structured with clear sections for the main purpose, return shape, example, and auth. The first sentence is front-loaded and the additional content (returns, example) is directly useful, though it could be condensed slightly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a read-only list tool with no output schema, so the description takes on the burden of explaining both usage and return values. It provides a full return structure, a concrete invocation example, and auth notes, making it highly complete for an agent to select and call correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 value by explaining the fantasy_filter for free agents/waivers and showing a full example with sort and limit. This goes beyond the raw schema descriptions and clarifies the intended usage pattern.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as the league's player pool with ownership %, ratings, projections, and injury status, and explicitly brands it as 'the waiver-wire tool'. This distinguishes it from sibling ESPN Fantasy tools by focusing on player data and free-agent/waiver use cases.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description tells users to 'pass a status filter for FREE AGENTS / WAIVERS' and provides a concrete example for top free agents, giving clear context for when to use it. However, it does not explicitly name alternatives or say when not to use it, just that it is the waiver-wire tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espn_web_callA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that auth is not needed, that it returns a JSON object, and specific operation details. It doesn't describe pagination or rate limits, but with annotations covering the safety profile, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and structured with clear sections (description, parameter hints, return type, auth). Every sentence provides useful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a multi-operation gateway with no output schema, it names the API host, lists operation categories, specifies parameter needs, states return type and auth. The pointer to the catalogue resource fills the gap for exhaustive operation details. Acceptable completeness, though it could mention pagination or error behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes the three generic parameters and references the catalogue. The description adds operation-specific parameter requirements (query/limit for search; sport/league/athleteId for athlete ops), which is valuable beyond the generic schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a gateway to the ESPN web API, enumerating specific operations (site-wide search, common/v3 athlete views, statistics-by-athlete) and the host endpoint. This differentiates it from sibling gateways like espn_site_call by naming the specific host and operation set.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states that `search` requires only query_params with {query, limit} and athlete_* ops require path_params with {sport, league, athleteId}, plus instructs browsing the espn://web/operations resource for valid operations. This provides clear operation-selection guidance, though it doesn't explicitly contrast against sibling tools for when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fanduel_racing_callA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering safety. The description adds valuable context: the query text lives server-side, boilerplate variables default automatically, auth is not needed, and returns a JSON object. It also states that guessing an operation returns an error (in schema description), which adds operational transparency 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  At four short sentences plus Returns/Auth lines, the description is compact and front-loaded. The first sentence immediately states the purpose, and every subsequent sentence adds information about operation discovery, defaults, return type, and auth.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a generic GraphQL caller with no output schema, but the description covers the key needs: how to discover operations, that variables are optional with defaults, that auth is not required, and the return format. It could be more explicit about error behavior or response structure, but the pointer to the operations resource and the schema's param descriptions fill most gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema descriptions are thorough (100% coverage): the operation parameter specifies valid names come from the catalogue resource and warns about errors, and the variables parameter explains that required keys depend on the operation. The description adds 'the boilerplate variables (brand/product/device/profile) default automatically, so most calls need no variables,' which helps the agent decide when to pass variables.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action: 'Call any FanDuel Racing (TVG) GraphQL operation by name + variables against api.racing.fanduel.com/cosmo/v1/graphql.' It specifies the verb (call), resource (FanDuel Racing GraphQL API), and scope (any operation), distinguishing it from sibling tools like fanduel_racing_messages or fanduel_sb_call.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description instructs the agent to 'Read fanduel://racing/operations for the operation list + variable signatures,' providing a clear next step for using the tool. It also explains that most calls need no variables due to automatic defaults, helping the agent decide when to omit variables. However, it does not explicitly state when to prefer dedicated FanDuel racing tools over this generic caller, so it lacks explicit exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fanduel_sb_callA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds context beyond annotations: it discloses that the tool carries the static public _ak web key and Origin/region headers, so the caller does not need to provide auth. It also mentions 'Auth: none needed' and points to the operations catalogue, which clarifies behavior. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tight and front-loaded with the core purpose, then the auth/headers context, then the catalogue pointer, and finally the return type and auth requirement. No filler or repetition; every sentence serves a purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a generic operation-based tool with rich schema descriptions and helpful annotations, the description covers the essential behavior: what it does, where to find operations, how auth is handled, and expected return type. It lacks specifics about error handling or pagination, but given the tool's nature and the schema's guidance, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with detailed descriptions for operation, path_params, and query_params. The description adds value by listing concrete examples of query parameters (eventId, customPageId, dataEntries, eventIds), giving the agent a sense of what kind of parameters are expected beyond the generic schema. This exceeds the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches a FanDuel Sportsbook REST resource by operation name, specifying the US/NJ region and the static public _ak web key plus Origin/region headers. This distinguishes it from sibling tools like fanduel_sb_live_score by positioning it as a generic operation-based caller, and it points to the catalogue resource for valid operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description tells the agent to read 'fanduel://sportsbook/operations' for the list of valid operations, which is an explicit prerequisite. It also explains that the caller only supplies variable query params, implying when to use this tool (after consulting the catalogue). It does not explicitly name alternatives or state when not to use it, but the context is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• footballdataorg_competition_matchesA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds significant behavioral context: the requirement of an API key (403 without), the unverified nature of the returned shape (from vendor docs, not tested live), and the instruction to inspect the actual payload. These go beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the purpose and includes essential details: auth requirement, return shape, a caveat about unverified data, and an example. It is somewhat redundant with the auth notice appearing twice ('NEEDS A KEY (403 without)' and 'Auth: needs your own key...'), which prevents a perfect score, but overall it is well-organized and informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no output schema, the description compensates by providing a detailed return shape (filters, resultSet, competition, matches with nested fields), a concrete example, auth requirements, and a warning about unverified field names. It also covers the key filters (matchday, season, date range, status). This is comprehensive for a read-only, idempotent tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage for all 6 parameters, so the schema already documents each parameter's meaning. The description adds no new parameter-level semantics beyond an illustrative example (competition=PL, matchday=1). With full schema coverage, a score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description begins with 'All matches in one competition,' which clearly states the tool's purpose: retrieving matches scoped to a single competition. This distinguishes it from sibling tools like footballdataorg_matches (all matches) and footballdataorg_competition (competition details). The example reinforces the scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you need matches for a specific competition, with optional filters like matchday, season, date range, or status. It provides a concrete example. However, it does not explicitly mention alternative tools or exclusions (e.g., 'for all matches across competitions, use footballdataorg_matches').

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_game_rulesA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral nuance: it works without a key, but FPL_SESSION_COOKIE unlocks more, and it details the return structure. This goes beyond what annotations provide, though less critical since annotations cover safety.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is informative but compact, with a clear first sentence, a structured return format example, and a note on auth. Each part serves a purpose, though the return example is verbose – acceptable because it doubles as documentation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 explain the return values; it does so thoroughly, including a breakdown of element_types and total_players meaning. It also covers authentication. This is complete for a zero-param read-only tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description no parameter semantics needed. It focuses on return content, which is appropriate and aligns with the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: it returns lookup tables for positions, chips, phases, and scoring settings. It explicitly distinguishes this tool as the reference for IDs used by other tools, which sets it apart from sibling tools that provide data itself.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains that this tool provides the lookup tables that other tools' ids refer to, and gives a concrete example (element_types resolves element_type id). This gives clear context for when to use it, but does not name specific alternative tools or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_gameweeksA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the description's addition of auth requirements ('works without a key; FPL_SESSION_COOKIE unlocks more if set') and the significance of key fields adds behavioral context beyond the structured data. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a concise summary, a comprehensive return schema, usage notes, and auth. It's front-loaded with key information. The field list is long but each element serves a purpose, so it's appropriately sized.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter read-only tool, this is exceptionally complete. It includes the return schema with field descriptions, clarifies critical fields (deadline_time, is_current/is_next), provides an example, and specifies auth behavior. The agent has everything needed to invoke and interpret the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters, the baseline is 4. The description doesn't need to explain parameter semantics; it supplements with a detailed return structure and field explanations, which is appropriate for a no-argument tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns all 38 gameweeks with deadlines, average scores, highest score, chip usage, and current gameweek. The 'Returns:' block explicitly details the response structure, making the purpose unmistakable. It distinguishes from sibling tools like fpl_fixtures and fpl_live_gameweek by focusing on the gameweek calendar and summary data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides actionable context: deadline_time is critical for knowing when transfers lock, and is_current/is_next help locate the season position without date arithmetic. This gives clear guidance on when to use the tool, though it does not explicitly name alternatives or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_h2h_leagueA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint/idempotentHint annotations, the description discloses key behaviors: the return structure, the distinction between total (H2H points) and points_for (FPL points), the ranking on total, the auth behavior (works without key, FPL_SESSION_COOKIE unlocks more), and the 404 on classic-league ids in the schema. This is rich, useful context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized and front-loaded with the core purpose. It uses a code block for the return shape and a separate example and auth note. However, it is slightly lengthy and the example ('An H2H table' followed by an input object) is a bit confusing, so it loses a point.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 explains the return payload, field meanings, ranking logic, and auth prerequisites. It also covers edge cases (404 for classic ids) and provides an example. This is a complete and self-contained description for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full coverage (100%) for both parameters, including that leagueId is an H2H league id from fpl_manager and that a classic-league id 404s. The description adds only a trivial example, so it does not meaningfully enhance parameter understanding beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description begins with 'Head-to-head league standings with win/draw/loss records,' clearly identifying the tool's function and resource. It differentiates from siblings like fpl_classic_league by explicitly focusing on H2H scoring and even notes in the schema that a classic-league id 404s, reinforcing the distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this is for H2H league standings, and the schema adds that classic-league ids are invalid. However, it does not explicitly name alternatives like fpl_classic_league or state when to prefer one over the other, so the guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_teamsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnly, openWorld, and idempotent hints. The description adds valuable context: the id is FPL's own 1-20, strength ratings are internal (~1000-1400), and auth works without a key. It does not mention potential errors or staleness, but for a simple zero-param tool this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with main description, return schema, id/strength notes, example, and auth. It is a bit lengthy but every section provides essential information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is complete for a tool with no parameters and no output schema: it explains the return structure, the id mapping, the strength rating scale, and authentication. No important details are missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so the description need not explain input semantics. It provides an example and notes on authentication, which is helpful. Baseline for zero params is 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns the 20 Premier League clubs with FPL's attack/defence strength ratings. It uses specific terms like 'FPL's attack/defence strength ratings' and explains the id is FPL's own 1-20, not the official PL id, which distinguishes it from sibling tools like pl_teams.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: it provides FPL-specific club data and strength ratings, and suggests joining to the premierleague provider by name for integration. However, it does not explicitly state when to use this tool versus alternatives like fpl_fixtures or pl_teams, nor provide exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• highlightly_soccer_highlightsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and open-world hints, lowering the bar for behavioral disclosure. The description goes far beyond by warning that `url` and `embedUrl` are not interchangeable, that the return shape is unverified vendor documentation and must be inspected, and that a personal API key is required—valuable context preventing misuse and unrealistic expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the purpose, followed by a compact return-shape block, a critical URL distinction, a verification caveat, a concrete example, and auth requirements. Every sentence earns its place without redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with no output schema, the description provides the essential return shape, a concrete example, auth requirements, and a useful caveat that the shape is approximate. It does not specify default behavior when no filter is provided or how multiple filters interact, but the annotations and schema fill most critical gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes all five parameters with 100% coverage, so the description need not compensate. The date example illustrates a valid usage pattern but adds little semantic meaning beyond the schema; no extra detail is given for matchId or leagueId formats, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning football highlight clips filterable by match, league, or date, with the phrase 'The main tool here' establishing its primary role among highlightly siblings. The verb+resource+scope is specific and unambiguous, distinguishing it from the broader set of tool names.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description frames the tool as the go-to for football highlights and provides a concrete date-based example, making when to use it clear. However, it does not explicitly name alternatives like highlightly_soccer_matches or highlightly_soccer_leagues or state when not to use this tool, so it stops short of full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• isportsapi_football_liveA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent. The description adds valuable behavioral context: the return shape is from vendor docs and unverified, the actual payload should be inspected, and a personal API key is required. This reliability caveat and auth requirement go beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and economically written: purpose, return shape, caveat, example, and auth. Every sentence contributes information; there is no fluff. The front-loaded purpose sentence immediately answers 'what does this do?'.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema, the description is thorough: it provides the return field names, distinguishes data placement, notes the unverified shape, includes an example, and gives auth information. It lacks explicit status vocabulary but is sufficient for an agent to select and invoke the tool safely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and an empty schema, so the baseline is 4. The description correctly focuses on the return shape and data placement rather than parameters. It adds no parameter details because none exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the resource and scope: 'Football matches in play now.' It distinguishes from siblings by noting that corners and cards 'live here rather than in a separate statistics call' and by the live vs. schedule/odds context of sibling tool names. Despite lacking an explicit verb, 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use it to get live in-play matches, and it explicitly indicates where to find corners/cards ('live here rather than in a separate statistics call'). It also states the auth prerequisite. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_eventA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable beyond-annotation context: the exact return shape and that no authentication is needed. This provides behavioral transparency that the annotations do not cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: a purpose sentence, a return shape, and an auth note. It is front-loaded with the core purpose and contains zero filler, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read tool with 2 fully documented parameters and rich annotations, the description is nearly complete. It provides the return structure and auth requirement, both important for invocation expectations. It doesn't discuss not-found errors, but that is an edge case beyond the required scope for this tool type.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the tool description's 'optionally with its markets embedded' simply restates the with_nested_markets parameter without adding new semantics. The schema already fully documents both parameters, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves a single event by ticker, optionally embedding its markets. This distinguishes it from sibling tools like kalshi_events (list of events) and kalshi_market (single market), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a singular lookup use case, and the schema's note that eventTicker comes from kalshi_events or a market's event_ticker provides workflow context. However, it stops short of explicitly naming alternatives for when not to use this tool, so it's clear but not fully prescriptive.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_eventsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, open-world, and idempotent behavior, so the description does not need to repeat those. It adds value by explaining the return structure (cursor, events, milestones), pagination behavior, auth requirement, and a worked example. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the core purpose, and efficiently packs return format, pagination, example, and auth into four short sentences. Every sentence contributes information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 provides the essential return fields and an example, making it largely self-contained. Minor missing details like sort order or the meaning of 'milestones' would improve completeness but are not critical for selecting or invoking the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All five parameters are documented in the schema (100% coverage), so the baseline is 3. The description adds explanatory context by mapping 'filter by series or status' to the relevant parameters, and the example demonstrates how to use `limit` and `status` together. This is above baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it is an 'Event catalogue' with an explicit definition of what an event is ('an event groups related markets'). It specifies the filterable dimensions (series, status) and mentions pagination, distinguishing it from singular tools like kalshi_event.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context for when to use it: as a catalogue for browsing/filtering events by series or status. Includes a concrete example (first page of open events) that demonstrates a use case. Does not explicitly name alternative tools, but the purpose is unambiguous enough that an agent can infer it from the sibling list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• kalshi_exchange_statusA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent behavior. The description adds useful context beyond annotations: that no auth is required and the exact return fields. This is adequate for a simple status endpoint, though it does not cover edge cases like error responses or data freshness.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: a single question and a single line stating the return fields and auth. Every sentence carries meaning, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple zero-parameter status check with no output schema, the description adequately specifies the return fields and auth requirements. It could explain the semantics of 'trading_active' vs 'exchange_active' in more depth, but the field names are self-explanatory and the tool's simplicity makes this acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema coverage is vacuous (100% for an empty schema). There is nothing for the description to add, so the baseline of 4 for zero-parameter tools applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool checks whether the exchange is currently up and trading, and returns specific fields (exchange_active, trading_active). This distinguishes it from siblings like kalshi_exchange_schedule and kalshi_exchange_announcements, which have different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this is a real-time status check ('right now') and notes that no authentication is needed. It does not explicitly mention alternatives or exclusion cases, but for such a simple, self-contained tool, the context is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• laliga_competitionA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already mark it as read-only, open-world, and idempotent. The description adds behavioral context: numeric IDs fail with 404, and it explains the auth model ('works without a key; LALIGA_SUBSCRIPTION_KEY unlocks more'). This is beyond annotation data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three compact sentences: what it returns, the return shape, and auth requirements. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter read tool, the description covers purpose, parameter format, failure mode, auth, and return structure. Since there's no output schema, the return example is particularly valuable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes the slug parameter with examples. The description reinforces this with 'e.g. primera-division' and warns against numeric IDs, adding practical selection guidance. No gaps remain.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'One competition by SLUG', clearly identifying a single-resource retrieval operation. It distinguishes from sibling list tool laliga_competitions by specifying singular access and gives an example slug.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says 'use the slug' and warns that numeric id 404s, providing a concrete usage rule. It doesn't compare to alternatives like laliga_competitions, but the singular scoping and slug guidance make the appropriate use clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• laliga_players_statsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Despite readOnlyHint and idempotentHint annotations, the description adds valuable behavioral context: 'Auth: works without a key; LALIGA_SUBSCRIPTION_KEY unlocks more if set,' page size cap of 100, and the exact response structure with the stats array. This covers authentication nuances, pagination constraints, and data shape beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with a clear main sentence, a Returns block, an Example block, and an Auth line. It is reasonably concise for the complexity, though the Returns block partially repeats the earlier mention of stats and player attributes. The front-loaded main sentence gives immediate purpose and the example is actionable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description fully specifies the return JSON structure, pagination behavior (limit max 100, offset), and authentication requirements. This is complete enough for an agent to select and invoke the tool correctly without needing additional information about response format or behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All three parameters (slug, limit, offset) are already described in the input schema with 100% coverage, so the baseline is 3. The description only reinforces these details by mentioning pagination and providing an example slug value ('laliga-easports-2025'), adding no new semantic meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'EVERY player in a season (≈749) with full Opta stats[] + position + team + opta_id.' This uses a specific resource and scope, distinguishing it from singular player tools like laliga_player_stats or laliga_player. The inclusion of 'EVERY player' implies a bulk listing operation, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context that this tool is for retrieving all players in a season, with pagination via limit/offset and an example. However, it does not explicitly state when not to use this tool or mention alternatives such as laliga_player or laliga_squad. The differentiation is implied by 'EVERY' rather than directly stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lichess_users_statusA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds useful context: no auth required, a hard 50-user limit, and an explicit return shape. This goes beyond the annotation metadata without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tightly packed: one headline sentence, return format, a minimal example, and an auth note. Every line earns its place and the most important info is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only batch status tool, this is largely complete: it specifies the limit, return fields, example input, and auth status. It does not cover edge cases like invalid usernames or over-limit behavior, but given the annotations and simplicity, the coverage is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers the single param fully, so baseline is 3. The description adds a concrete example showing ids as an array, which clarifies usage. Note: the schema description says 'comma-joined' while the example shows an array, which is slightly confusing, but the example still adds practical meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Online/playing status for up to 50 users in one call — who is available right now,' which clearly identifies the resource (Lichess user statuses), the action (fetching status), and the batch scope. It also lists the exact return fields, distinguishing it from single-user tools like lichess_user.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'in one call' and the 50-user cap establish when to use this tool: when you need status for multiple users at once. It also states 'Auth: none needed,' clarifying prerequisites. However, it does not explicitly name alternatives or say when not to use it, so it stops short of a full when/when-not guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mysportsfeeds_injuriesA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent. The description adds valuable behavioral context beyond that: return shape from vendor docs is unverified, own API key required, no season segment exists. This caveat prevents the agent from relying on unverified field names, which is significant transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a one-sentence summary, return shape, caveat, example, auth, and alternatives. Every section carries information, but the 'Also answers this' phrasing is slightly cryptic and the caveat is repeated across two sentences, adding minor redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with 3 params (1 required), no output schema, and annotations present, the description is complete: it gives expected shape, example input, auth requirements, time-scope limitation, and alternative tool mappings. An agent has enough to safely select and invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — league, team, and player are each described in the schema. The description adds an example ('league': 'nba') and notes league is part of the URL path, but this mostly restates schema info. Per the rubric, baseline 3 is appropriate 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The first sentence 'Current injury list for a league' uses a specific verb (list) and resource (injuries) with clear scope. It distinguishes from siblings by focusing on injuries, and the 'Also answers this' line explicitly maps to related tools (espn_site_call, espnfantasy_player_info, sportsdataio_nfl_injuries), showing how it differs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: it is for current injuries only ('no season segment — always now'), and lists alternative tools it can replace. However, it does not explicitly state when to prefer a sibling tool (e.g., sportsdataio_nfl_injuries) over this one, so it stops short of full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_stat_leadersA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the return shape ({type, count, data:[...]}), explicitly states auth is not needed, and clarifies the ID source. These are behavioral details beyond what the annotations (readOnlyHint, openWorldHint, idempotentHint) already declare. It does not contradict the annotations and provides a safe, read-only operation context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tight and well-structured: a clear first sentence defines the purpose, followed by the key ID source caveat, return shape, a concrete example, and auth note. Every sentence earns its place, and the most critical usage information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description provides a return shape example and explains all parameters well. It covers the essential context: what the tool does, how to identify the season, how to paginate, and what the output looks like. It could mention behavior on invalid seasonId or empty results, but overall it is complete enough for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description adds meaning beyond the schema by explaining that seasonId comes from nbl_seasons (data[].id) and must not be the year. It also gives a real example for sort (-points_average) and limit (limit=-1 for all), making the parameter semantics clearer and more actionable.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: retrieving season statistical leaders (points, rebounds, assists, etc. averages) per player for a single season. It specifies the resource (season leaders) and distinguishes from siblings like nbl_player_stats (per-player game stats) and nbl_team_stats (team stats) by emphasizing per-player averages and season-level aggregation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit guidance on how to use the tool: pass the season UUID from nbl_seasons, NOT the year, and use limit to cap rows. It provides a concrete example with a real seasonId and sort parameter. It does not explicitly name alternative tools for exclusion, but the context about the correct seasonId source is a clear usage guideline that adds value beyond the schema.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nrl_competitionsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds 'Auth: none needed' and the exact return structure ({competitionDetails:{competition:[...]}}), which are valuable behavioral details beyond annotations. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized and efficiently communicates purpose, return format, example usage, and auth status in a few short blocks. It's concise but not minimal, with the example and return structure adding practical value without verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given a simple no-parameter read-only tool with no output schema, the description is complete: it covers what data is returned, the exact JSON shape, the downstream usage (nrl_fixture/nrl_match), and auth requirements. An agent can confidently invoke this tool and interpret results without additional context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Tool has zero parameters and schema coverage is 100%, so there is no parameter documentation burden. The description correctly focuses on what the returned data contains and how to use it, which is the relevant semantic guidance for a no-arg tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns all Champion Data competition IDs with season and round counts, and explicitly positions it as the lookup for NRL competitionId (e.g., 12999 = 2026 NRL Premiership) to pass to nrl_fixture/nrl_match. This distinguishes it from other competition catalogues (pl_competitions, laliga_competitions) via its specific NRL/Champion Data focus.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It says to use this tool to find the NRL competitionId before calling nrl_fixture/nrl_match, providing concrete examples. It doesn't explicitly state when not to use it or name alternative competition catalogues, but the context is clear for the intended NRL workflow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_sport_matchups_allA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds genuinely useful behavioral context beyond annotations: the exact return shape ("[{id, league:{name}, participants:[...], startTime, hasMarkets, isLive}]"), the "top-level array" structure, and "Auth: none needed." It adds valuable operational detail without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the purpose, followed by compact sections for return shape, a concrete example, and auth requirements. Every line contributes unique information with no redundancy or filler. It is appropriately sized for a simple one-parameter read tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema present, the description correctly shoulders the burden of describing the return value, and it does so explicitly. The example and auth note round out what an agent needs for this simple, annotated read-only tool. It could be more complete by explicitly differentiating itself from live and league-scoped siblings (`pinnacle_sport_matchups_live`, `pinnacle_league_matchups`), but the "not just highlighted" note covers the primary sibling.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for sportId, stating it comes from `pinnacle_sports` and is a URL path component. The description adds a concrete worked example ({"sportId": 3} for baseball), giving the agent a grounded value to verify its call against the return structure. This is a modest but real addition beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description leads with a clear, specific verb+resource: "All matchups for one sport (the full list, not just highlighted)." The parenthetical explicitly contrasts this with a highlighted-only version, which distinguishes it from the sibling tool `pinnacle_sport_matchups`. The baseball example further reinforces the intended scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase "the full list, not just highlighted" provides clear context on when to use this tool (get every matchup for a sport) versus a featured/highlighted subset. However, it never explicitly names the alternative tool (`pinnacle_sport_matchups`) or states when NOT to use it (e.g., live-only should use `pinnacle_sport_matchups_live`), so it stops short of full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_clubs_metadataA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description supplements the annotations by specifying the return shape (top-level array of objects with id, name, stadium, website) and stating no authentication is required. It also characterizes the data as a 'static config blob,' implying immutability. No contradictions with the read-only and idempotent hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: one main sentence, a return type line, and an auth note. Every line adds distinct value, and the return format is front-loaded with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, return structure, and authentication in just a few lines, rendering the tool understandable without an output schema. Minor gap: it mentions 'colours' in the opening but omits it from the return sample, which could cause slight ambiguity about the actual response fields.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is no parameter schema to explain. The baseline for zero-parameter tools is 4, and the description appropriately focuses on output rather than inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides club metadata (names, stadiums, websites, colours) specifically for theming, distinguishing it from sibling tools like pl_teams that serve different purposes. The 'static config blob' label further clarifies its precise role.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'for theming' provides clear context for when to use this tool, and 'Auth: none needed' simplifies access expectations. It doesn't explicitly name alternatives or contrasting tools, but the use case is specific enough to guide an agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_matchesA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so no contradiction. The description adds valuable behavioral context beyond annotations: it states pagination, provides the exact return structure with fields, notes 'Auth: none needed', and gives a working example. This exceeds the baseline for annotation-covered tools.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the first sentence states purpose and filters, followed by a return schema, a concrete example, and auth note. Each element earns its place, though the response block is slightly verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 10 parameters and no output schema, the description compensates richly: it declares pagination, provides a full return object shape, includes an example query, and confirms auth is unnecessary. This gives an agent enough context to invoke the tool and interpret results correctly, even without an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers 100% of parameters, so baseline is 3. The description enhances this by listing the filterable categories and providing a concrete example showing how to combine competition:8, season:2025, and matchweek:1. It also clarifies the period enum values. This adds integration-level meaning beyond raw schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Primary fixtures/results feed', clearly identifying the tool as a list/query endpoint for match data. It names the specific resource (fixtures/results) and enumerates filter dimensions (competition, season, matchweek, team, period, kickoff date range), distinguishing it from singular siblings like pl_match or specific pl_matchweek_matches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Primary fixtures/results feed' signals this is the default choice for match listings, and the example shows a concrete usage (2025/26 matchweek 1). However, it does not explicitly state when to use alternatives like pl_match or pl_matchweek_matches, nor does it mention exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_playerA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint and idempotentHint annotations, the description adds 'Auth: none needed' and the exact return shape, including a top-level array with one entry per spell. This gives agents actionable behavioral knowledge.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a purpose line, a return format line, and an auth line. All information is front-loaded with no unnecessary fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with one parameter, it explains output shape and auth sufficiently. Minor deduction: the first sentence mentions fields like weight, shirtNum, and preferredFoot that do not appear in the return example, creating slight ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes pid ('Player id. Required — part of the URL path') with 100% coverage, and the description adds no additional parameter meaning. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Full player career' and specifies the granularity as 'one entry per club/season spell', listing key fields like height/weight, shirtNum, preferredFoot, and position. This distinguishes it from sibling tools such as pl_player_basic or pl_player_info.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context—it is for full career history with per-spell entries—but does not explicitly mention alternatives or when not to use it. This earns a 4 rather than a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_sport_featured_eventsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, open-world, and idempotent hints. The description adds valuable context: 'Auth: none needed' and a detailed return structure. It also clarifies the tool only returns event headers, not markets, which is behavior 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: two sentences plus a return type line. Every sentence provides necessary information (purpose, alternative, return shape, auth), with no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool, the description is quite complete: it states the input, output structure, auth requirements, and related tool usage. It lacks details like pagination or what 'featured' means, but these are not critical for such a tool, and the return structure compensates for the lack of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the only parameter (sportKey), which already explains it is a required sport slug and part of the URL path. The description adds no additional parameter semantics, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: fetching featured (highlighted) events for a single sport. It uses a specific verb+resource ('Featured events for one sport') and distinguishes itself from the sibling tool pointsbet_event by explicitly directing market calls to that tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: 'call pointsbet_event for markets' indicates an alternative tool for a different purpose (markets vs. event headers). This tells the agent when to use this tool (to get event headers) and when not to (when markets are needed).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sleeper_traded_picksA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds valuable behavioral details: the exact return structure with field semantics ('roster_id is the pick's ORIGINAL owner; owner_id holds it now') and 'Auth: none needed.' This goes beyond the annotation baseline, so it earns a 5.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured, with clear sections for purpose, return format, example, and auth. The example request is helpful but presented as a single-line JSON block that could be slightly clearer. Overall, it is efficient and front-loaded, earning a 4.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read endpoint, the description is complete. It explains the return fields and their meanings, notes that no auth is needed, and provides an example. Since there is no output schema, the description effectively fills that gap, making it fully sufficient for an agent to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage for the single parameter league_id with the description 'League id. Required — part of the URL path.' The tool description adds no further semantic detail about the parameter beyond an example request, so it remains at the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Draft picks that have changed hands — who owns which future pick (dynasty leagues).' It specifies the exact resource (traded draft picks) and scope (dynasty leagues), and the 'Returns:' line further clarifies the output structure. This distinguishes it from sibling tools like sleeper_draft_picks by focusing on traded picks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: when needing ownership of traded future picks in dynasty leagues. However, it does not explicitly mention alternatives or when not to use it (e.g., for all draft picks use sleeper_draft_picks). Since context is clear but exclusions are absent, it earns a 4.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportmonks_livescoresA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations by disclosing that the return shape is from vendor docs and not verified against a live response, warning the agent to treat it as approximate. It also explains how to interpret periods[].ticking for running vs. paused clocks, and mentions the required auth token. These details provide practical behavioral context that annotations alone lack.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear opening, return shape, caveat, example, and auth note. Each section serves a purpose, though it is slightly verbose with the unverified shape note and example. It is not bloated, but could be tightened without losing value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with no output schema, the description provides the return structure, usage example, auth requirements, and a reliability caveat. This is comprehensive enough for an agent to invoke the tool and interpret the response correctly, even without prior knowledge of the Sportmonks API.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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's example with include='participants;scores' demonstrates usage but does not add new semantic meaning beyond the schema's example ('participants;scores;events'). It is somewhat redundant, so no higher score is warranted.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Fixtures in progress now,' which clearly identifies it as a live/in-progress fixtures tool. This distinguishes it from siblings like sportmonks_fixtures_by_date and sportmonks_fixture by focusing on the current time. The purpose is unambiguous and action-oriented.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use it (live/in-play fixtures) and includes a concrete usage example with the include parameter. However, it does not explicitly mention alternatives or when not to use this tool, such as needing fixtures for a specific date (use sportmonks_fixtures_by_date) or a single fixture (use sportmonks_fixture).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsbet_racing_multis_eventsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by specifying the ordering behavior ('next-to-jump'), the return structure (events with eventId, raceNumber, advertisedStartTime, meetingName), and that no auth is needed. This complements the annotations without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very concise: one opening sentence stating the purpose and ordering, followed by a compact return type and auth note. Every line earns its place, with no redundant or vague filler. The structure front-loads the primary purpose and then provides concrete details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, read-only listing tool with strong annotations, the description covers the essentials: what data is returned, the ordering, and authentication requirements. The inline return schema compensates for the missing output schema. Minor gaps like pagination or field descriptions are not critical for this simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the input schema is empty, so parameter documentation is not needed. The description provides a sample return object, which is more useful than any parameter explanation. Baseline for 0 params is 4, and the description fully satisfies this.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Events available for racing multis' with a specific ordering ('next-to-jump style feed'). This distinguishes it from sibling tools like sportsbet_racing_allracing or tab_racing_next_to_go by focusing specifically on multis events, making the resource and scope unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it's a feed of upcoming racing events for multis, ordered by start time. While it doesn't explicitly name alternatives or state when not to use it, the specific use case ('racing multis') and feed style imply the appropriate context. No misleading exclusions are present.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsdataio_nfl_dfs_slatesA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnlyHint, idempotentHint), the description adds critical caveats: the return shape is 'from vendor docs' and 'has NOT been verified against a live response,' advising agents to inspect actual payloads. It also clarifies field semantics (FantasyPointsPerDollar is value; salaries are integer dollars) and documents auth requirements via specific env vars.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is structured into purpose, return shape, caveat, example, and auth sections, all relevant. It is somewhat long but each sentence delivers necessary information for a complex tool; no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a detailed return shape including nested fields (DfsSlateGames, DfsSlatePlayers) and types, plus a reliability warning and example invocation. Auth requirements are also covered, making the tool fully usable by an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and both season and week are described as required URL path parts. The description adds a concrete example (season 2023, week 1) but no additional parameter semantics beyond the schema, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this tool returns 'DFS slates and player SALARIES for a week' across DraftKings, FanDuel, and Yahoo, and specifically notes it's not available from official NFL feeds. This distinguishes it from sibling tools like sportsdataio_nfl_scores, sportsdataio_nfl_teams, and sportsdataio_nba_dfs_slates.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for DFS salary data with 'Not available from the official NFL feeds,' suggesting when to prefer this tool. It provides an example call, but does not explicitly name alternative tools or state when NOT to use this one, though the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsdataio_nhl_games_by_dateA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description proactively warns that the return shape is unverified and approximate, which is important behavioral context beyond the readOnlyHint/openWorldHint annotations. It also discloses the auth dependency (env key) and that the shape may not match live responses, adding transparency about potential discrepancies.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections: purpose, return shape, caveat, example, and auth. While longer than minimal, every section earns its place, though the 'SHAPE FROM VENDOR DOCS' line and the following NOTE somewhat redundantly repeat the unverified nature of the shape.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool, the description covers all essential context: what it returns (with field list), how to call it (example), prerequisites (auth key), and a critical reliability caveat. It also points to an alternative for more detailed data, making the tool usable standalone without additional documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes the single `date` parameter with format and requirement. The description adds a concrete example value and notes the date is part of the URL path, but this provides marginal additional meaning beyond the schema's 100% coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states exactly what the tool does: returns NHL games for a given date, including betting lines ('with the line'). It identifies the resource (NHL games), the filter (date), and the additional data (point spread/over-under), making it distinguishable from sibling NBA/MLB date-based tools and other NHL providers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly directs users to the keyless official `nhl` provider for deeper play-by-play and box scores, clearly delineating when to use this tool versus an alternative. It also provides an example call and auth key requirements, giving concrete usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsgameodds_eventsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations, detailing the exact return shape, the nested odds object keyed by oddID, and the two-level byBookmaker dictionary. It also warns that the shape is unverified and should be treated as approximate, and explains authentication needs. This adds significant context the annotations don't cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately long but each section earns its place: purpose, return shape, caveat, example, and auth. The structure is logical and front-loaded, though the return shape block is dense and could be slightly reorganized for scannability.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 specifying the return structure, nested dictionaries, pagination via nextCursor, and the unverified nature of the vendor docs. It also covers authorization and provides a concrete example, making it complete for a complex, read-only odds tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds an example combining leagueID and oddsAvailable, which provides some practical context, but it doesn't add detailed semantics per parameter beyond what the schema already gives.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Events with their odds attached, including player props' and calls it 'The main tool here,' which differentiates it from sibling sportsgameodds tools and other odds providers. The verb+resource is specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description positions this as the primary events-with-odds tool for the provider and includes an example with leagueID and oddsAvailable to show typical usage. However, it doesn't explicitly mention when to prefer alternative tools or any exclusions, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_racing_futures_raceA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the read-only nature via annotations (readOnlyHint), and adds that it works without auth but can unlock more with keys. It also specifies the return structure, providing transparency about expected output. It does not contradict any annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, covering purpose, return structure, and auth in a few sentences without unnecessary detail. It is well-structured and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description provides the return shape in text, which is adequate. It gives context about futures markets and why this tool exists. It lacks info on error handling or edge cases but is complete for the tool's core functionality.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All parameters are well described in the schema (date, raceName, raceType, fixedOdds, jurisdiction, venueMnemonic). The description reinforces the key parameter raceName by explaining the naming convention. It adds value by clarifying the race slot usage, though it does not elaborate on parameter constraints beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: retrieving a racecard for a single futures market. It distinguishes itself from tab_racing_race by explaining the naming convention (race name vs. integer) and explicitly mentions it cannot be reached by that tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when dealing with futures races identified by name, contrasting with the integer-based tab_racing_race. It also mentions auth requirements, giving context for when additional credentials might be needed. While not an explicit step-by-step usage guide, it provides enough situational guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• theoddsapi_event_oddsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly and idempotent annotations, the description discloses the return structure, warns that the shape is unverified and approximate, advises inspecting the actual payload, and notes the auth key requirement. This is honest and thorough about reliability.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections: purpose, return schema, reliability note, example, and auth. It is slightly long but every part adds value—especially the inline return schema and the unverified-payload warning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description compensates with an inline return schema, an example, an explicit reliability caveat, and auth requirements. All parameters are covered by the schema. The tool is effectively fully specified for its purpose.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all five parameters with 100% coverage. The description adds an example call and clarifies the eventId source, but no additional parameter-specific semantics beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states 'Odds for ONE event' and distinguishes it from the 'competition-wide call' (theoddsapi_odds). It specifies the resource (event odds) and scope (single event, including player props), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when you need single-event odds, player props, or markets not available on the competition-wide call. It contrasts the single-object return with the competition call's array, but does not explicitly state when not to use it or list alternative tool names.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• theoddsapi_scoresA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, idempotentHint), the description adds critical context: the exact return shape, that scores is null until game start, score values are strings, and a warning that the shape is unverified from vendor docs. It also explicitly mentions auth requirements. This goes well beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with purpose, return type, note, example, and auth sections. It front-loads the core purpose and each section earns its place, though it is slightly verbose. Still efficient for the complexity involved.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description fully specifies the return shape, data types, null behavior, and provides an example. It also flags the unverified vendor doc shape, which is crucial for agent decision-making. The tool is simple enough that this is complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with descriptions for all three parameters. The description's example adds a mild illustration but does not introduce new semantic meaning beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Live and recently-completed scores for a competition', which uses a specific verb and resource. It clearly distinguishes this scores tool from sibling tools like theoddsapi_odds and theoddsapi_events.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context and a concrete example (EPL scores with sport and daysFrom), but it does not explicitly mention alternatives or when not to use this tool. It implies usage via the example but lacks direct comparisons to sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_league_scoreboardA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint/openWorldHint/idempotentHint annotations, the description discloses the response shape is unverified from vendor docs, advises inspecting the actual payload, explains projected points are included, and states auth requirements. This is substantial behavioral context with no contradiction of annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose and then provides a structured return shape, caveat, example, and auth note. It is somewhat long due to the inline JSON shape, but each block serves a purpose; minor redundancy in the vendor-docs caution keeps it from being maximally tight.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description supplies a detailed return shape, explicitly flags that the shape is unverified, provides a usage example, and tells the agent how auth is configured. It is unusually complete for an API wrapper, especially given the provider-specific complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with leagueKey and week already described as required URL path parts. The description adds only a concrete example and does not significantly extend parameter meaning beyond the schema, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'One week's matchups with both teams' points — live during a week, final after.' This clearly identifies the tool as a weekly fantasy scoreboard and distinguishes it from standings or roster tools. The name 'yahoo_league_scoreboard' is directly reinforced rather than merely restated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: it is for one week's matchups, with live/final points, and notes that projected points are what 'an in-week win-probability read needs.' It does not explicitly name sibling alternatives or state when not to use it, so it stops short of a perfect score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_compseason_getA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly, idempotent, openWorld), the description adds 'Auth: none needed' and the exact return shape, which is valuable for an agent to anticipate the response. This goes well beyond the structured data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the main action. The return block and auth note are directly useful and contain no redundancy. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple nature of the tool (single parameter, read-only, getter), the description is complete: it covers the return structure, auth requirement, and the distinguishing 'embeds full rounds array'. No output schema exists, so the described return shape helps fill that gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides a complete description for compSeasonId, including an example and note that it's part of the URL path. The tool description adds no additional parameter semantics, so the baseline 3 is appropriate given full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and specific resource ('single comp season'), and clearly differentiates from siblings by noting it embeds the full rounds array and currentRoundNumber. This distinguishes it from list-style tools like afl_compseasons_list or afl_rounds_list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly conveys that this tool is for retrieving a specific comp season by ID, and the mention of embedded rounds implies use cases where round data is needed. It does not explicitly name alternative tools or state exclusions, but the context is clear enough for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_live_videoA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint/idempotentHint annotations, the description discloses that no authentication is needed, returns empty when no game is live, and provides the exact return structure. These are valuable behavioral facts not covered by annotations or schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: the first sentence states the core purpose, followed by return structure, auth, and sibling alternatives. Every sentence adds value and there is no wasted text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with well-documented parameters, the description covers all essential context: return shape, auth, empty behavior, and related tools. It is complete without needing an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptive parameter names and descriptions for round, pageSize, and compseason. The tool description does not add extra parameter semantics, so it stays at the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides live AFL video streams, with the key behavior of returning empty when no game is live. It distinguishes itself from siblings like afl_live_audio by specifying video, and it even names alternative tools it can answer for (cricketaustralia_streams, entain_video_channels, pointsbet_inplay_streaming).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use this tool (needing live AFL video streams) and notes the 'Also answers this' alternatives, which helps route mental queries. It does not explicitly state when not to use it, but the context is sufficient given the tool's simplicity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• afl_player_getA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context: 'Auth: none needed' and the exact return structure, which is not included in structured fields. No contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, with just two sentences covering purpose, return format, and auth. Every element is useful and there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter lookup tool, the description covers essential aspects: what it does, the return shape, and authentication requirements. No output schema exists, but the inline return format compensates. The description is complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the parameter schema fully explains playerId's source and requirement. The tool description adds no additional parameter semantics 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get a single player by id' and specifies the content areas (bio, draft, height/weight). This distinguishes it from sibling tools like afl_players_list, which are for bulk retrieval.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context for fetching a single player, and the parameter schema mentions 'from afl_players_list', indicating a prerequisite. However, it does not explicitly state when to use this tool over alternatives or provide exclusionary guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_football_fixture_statisticsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnly, openWorld, idempotent), the description discloses the long-format return structure, potential string values with percent signs, the unverified nature of the vendor-documented shape, and the need for an API key. These warnings significantly help the agent handle unexpected payloads.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence earns its place: purpose, return shape, format caveat, verification warning, example, and auth requirement. It is compact yet information-dense, with the essential purpose front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (two params, one required), and the description covers the return format with an example, warns about data reliability, notes the optional team param's behavior, and clarifies auth. This is complete for its complexity, especially for a read-only, idempotent operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes both parameters well (fixture: 'Fixture id.', team: 'Only this team's column.'). The description adds an example using fixture but no new semantics beyond what the schema provides. Baseline 3 applies due to 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Team match statistics for one fixture — shots, possession, corners, and expected goals where covered.' This clearly states the tool's scope and distinguishes it from sibling tools like apisports_football_fixtures or apisports_football_predictions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly contextualizes when to use the tool: when team match statistics for a single fixture are needed. It does not explicitly name alternatives or exclusions, but its focused scope makes the use case unambiguous. The example input reinforces this.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_football_h2hA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations stating read-only and idempotent behavior, the description discloses the return shape, warns that the shape is unverified from vendor docs and not tested against live data, and notes that the caller must supply their own API key. This is valuable context that helps an agent set expectations and handle potential surprises.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with distinct sections: the core purpose line, return shape, vendor caveat, example, and auth note. Each section earns its place with no fluff, and the structure front-loads the most important information for fast scanning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description provides the expected response shape, an illustrative example, and an honest caveat about its reliability. Combined with the annotations, this gives an agent sufficient context to call the tool and interpret results, making it complete for a read-only fixture-history endpoint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes all three parameters with 100% coverage, so the description does not need to compensate. The example {'h2h': '33-34', 'last': 10} adds a concrete illustration but does not introduce semantically unique information beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Every past meeting between two clubs,' which is a specific verb+resource statement that clearly defines the tool's purpose. It also distinguishes itself from sibling tools like apisports_football_fixtures by referencing 'same fixture shape,' which contextualizes the output while making the h2h specialization clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the intended use case unambiguous ('Every past meeting between two clubs') and provides a concrete example for invoking the tool. It does not explicitly name alternatives or state when not to use it, but the purpose is clear enough that an agent can select it appropriately 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.

• apisports_football_oddsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/openWorld/idempotent annotations, the description discloses critical behavioral traits: the return shape is from vendor docs and unverified (no key held), odds are strings, and the actual payload should be inspected before relying on field names. This is honest and valuable context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with sections for return shape, caveat, example, and auth. It is a bit long, but every part adds necessary value, especially the unverified-shape warning. The front-loaded purpose is effective.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 convey the return structure, which it does with an explicit shape example. It also covers auth, parameter usage via example, and the reliability caveat. This is complete for a read-only odds tool with an approximate vendor schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, providing baseline 3. The description adds an example using 'fixture' and explains the two main query modes (fixture or league), which enriches parameter understanding beyond the schema's per-field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Pre-match odds from many bookmakers for a fixture or league', which identifies both the resource and the scope. It differentiates from sibling tools by focusing on odds and pre-match, but lacks an explicit imperative verb like 'retrieve'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: 'For AU markets the direct providers here (sportsbet, tab, pointsbet) are deeper and live.' This names alternatives and the condition for preferring them over this tool, which is exactly the kind of when-to-use vs alternatives guidance needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_handball_gamesA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, open-world, and idempotent hints, but the description adds substantial context: a detailed return shape, score interpretation guidance (handball scores run 25-35 and under 10 usually indicates first half), an explicit warning that the shape is unverified from live responses, and an auth requirement. This goes well beyond what annotations provide and helps the agent set expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded: the first sentence states the core purpose, followed by essential return shape, practical notes, a concrete example, and auth info. Every sentence provides value—no filler or tautology.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description takes on the burden of explaining return values and does so thoroughly with the response shape and field-level hints. It also covers score interpretation, unverified shape caveat, a usage example, and authentication. For a 4-parameter read-only sports data tool, this is complete and highly informative.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for all four parameters (date, team, league, season). The description only adds an example for 'date' and mentions 'by date or league', which doesn't meaningfully extend the schema's parameter documentation. Baseline 3 is appropriate when the schema handles parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides handball games from specific leagues (EHF Champions League, Bundesliga, LNH and others) by date or league. It distinguishes itself from sibling sports game tools by naming the sport and leagues, and includes return shape details that remove ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context on when to use it (for handball games, filtered by date or league) with a concrete example. However, it does not explicitly mention alternatives or exclusionary guidance (e.g., 'for football use apisports_football_fixtures'), so it doesn't fully meet the 'when-not/alternatives' bar.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_volleyball_gamesA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Goes beyond the readOnly/idempotent annotations by disclosing the critical semantic trap (scores is sets won, not points), warning that the return shape is unverified from vendor docs, and stating auth requirements. This is exceptional context that prevents misuse.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Well-structured with labeled sections (Returns, NOTE, Example, Auth). Every sentence adds value, including the trap warning and the vendor-verification caveat. Front-loaded with the most important usage information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description fully compensates by providing the return shape, field meanings, the sets-vs-points trap, and an authentication requirement. It also flags the unverified nature, which is crucial for an agent. Complete for a read-only sports data tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers all 4 parameters with descriptions (100% coverage). Description adds a usage example and mentions 'by date or league' but does not elaborate on team or season beyond schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States clearly it returns volleyball games, specifying leagues (Italian SuperLega, Polish PlusLiga, CEV) and the filtering dimensions (by date or league). This distinguishes it from sibling apisports_* tools for other sports.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides context: use for volleyball games by date or league, with a concrete example for date. Does not explicitly exclude other tools, but the sport-specific scope is obvious given siblings. Lacks explicit 'when not to use' guidance, so not a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cfbd_betting_linesA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations (readOnlyHint, openWorldHint, idempotentHint) by disclosing that the return shape is from vendor docs and 'has NOT been verified against a live response,' advising to 'inspect the actual payload.' It also explains the significance of `*Open` fields for CLV comparisons and notes the auth requirement (CFBD_API_KEY). This adds valuable context without contradicting the safe-read annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized and front-loaded: it opens with a one-sentence purpose, then presents the return shape, a caveat about verification, an example, and auth requirement. Each section serves a clear purpose and there is no fluff. It is longer than average but every sentence earns its place due to the tool's complexity and the unverified data warning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that there is no output schema and the return payload is complex (nested `lines` objects), the description compensates by providing a detailed return shape, explaining it is approximate, giving an example call, and stating the auth key requirement. It also clarifies the `*Open` versus closing semantics, making it complete for an agent to understand both the call and the response structure.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers all four parameters (team, week, year, seasonType) with descriptions, providing 100% coverage. The description does not elaborate on parameter meanings or formats beyond the schema, except for an example using year and week. This example adds a hint of usage but does not substantially enrich parameter semantics, aligning with the baseline for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as retrieving 'Historical betting lines per game from multiple books — spread, over/under and moneyline.' It specifies the resource (betting lines), the scope (per game), and the content (spread, totals, moneyline), which distinguishes it from sibling tools like cfbd_games or odds aggregation tools. The phrase 'The college-football backtesting dataset' further clarifies its intended use.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description sets clear context: it is for historical betting lines and backtesting, and it provides a concrete example query (2024 week 1 lines). However, it does not explicitly state when to prefer this over alternatives such as cfbd_games or theoddsapi, nor does it mention exclusions. The usage intent is implied but not explicitly contrasted with other tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• chesscom_monthly_gamesA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds substantial behavioral context beyond these: the return format (games array with specific fields), that 'end_time' is UNIX SECONDS, that a prolific player's month can be several MB, and that no authentication is needed. This warns the agent about potential payload size and response structure, which is valuable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded: the first sentence states the purpose, followed by the return format, a key note on time units and size, a concrete example, and auth requirement. Every sentence earns its place, and the formatting is scannable and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 it does so thoroughly. It specifies the nested structure of games, highlights the high-risk 'several MB' size, provides a realistic example, and states auth requirements. This is complete for a read-only, idempotent data retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter clearly described (e.g., 'Two-digit month, ZERO-PADDED'). The description adds an example (hikaru, 2025, 01) but this largely reaffirms schema details rather than providing new semantic information. The baseline of 3 applies because the schema handles parameter documentation, and the description adds minimal extra value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Every game a player finished in one month, with PGN, result, ratings and opening ECO.' This specifies the verb (finished/returns), resource (games), and scope (one player-month), distinguishing it from sibling tools like chesscom_player or chesscom_player_stats which focus on profiles or aggregate stats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for use: it returns games for a specific player in a month, with an example showing required parameters. However, it does not explicitly state when not to use it or mention alternative tools for other scenarios (e.g., getting stats or archives), so it lacks explicit exclusions or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• chesscom_player_statsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it specifies that a key is absent if the player has never played a format, and discloses that no authentication is required. This goes beyond the structured metadata.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and appropriately sized: it opens with the core purpose, then details the return shape, provides an example, and ends with authentication info. Every section earns its place without redundant fluff. The inline return structure is necessary since there is no output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description fully compensates by detailing the exact return structure (nested objects for each format, records, best ratings, etc.) and the edge case of missing keys. It also includes a practical example and notes that no auth is needed, making the tool's input and output completely clear for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully describes the 'username' parameter with 100% coverage, so the baseline is 3. The description adds value by providing a concrete example of the parameter usage ({"username": "hikaru"}), which clarifies how to specify the username in practice. This extra illustration enhances understanding beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves a player's ratings and records per game type (blitz, bullet, rapid, daily, tactics, puzzle rush). It uses a specific resource (Chess.com player) and differentiates from sibling tools like chesscom_player by enumerating the exact statistics returned. The purpose is unmistakable and aligns with the tool name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: when you need a player's ratings and records across various chess formats. It includes an example invocation and notes that no authentication is needed, but it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cricketaustralia_toursA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the tool as read-only, open-world, and idempotent, but the description adds substantial context: the exact return object structure, the meaning of status flags (upcoming/in-progress/completed), and an explicit 'Auth: none needed' statement. This goes well beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: three short sentences plus a return-type block. It is front-loaded with the core purpose, followed by the output shape and auth, with no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only feed with two optional parameters and no output schema, the description fully covers the purpose, data semantics, return structure, and authentication requirements. An agent has enough information to decide when to call it and interpret the response confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of the parameters (format and jsconfig) with descriptions, so the baseline is 3. The description adds no additional parameter information or context beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning tours/series with status flags and grouping competitions, and explicitly states it is the feed behind the site's series navigation. This resource-specific framing distinguishes it from sibling tools like fixtures or competitions without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context (tour-level feed for series navigation) but does not explicitly name when to avoid this tool or point to alternatives like cricketaustralia_fixtures for match-level data. The guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dabble_sportsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds useful context beyond that: it states that auth is not needed, and it discloses the exact return shape ({status, data:[{id, name, isRacing, isHidden}]}) and the fixed count of 24 sports. This gives the agent a solid understanding of what to expect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly concise and well-structured: it leads with the core purpose, then the return shape, then auth. Every sentence earns its place. No fluff or repetition of schema data.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple lookup tool with no parameters, the description is fully complete. It explains the returned fields, the function (join with competitions), and authentication requirements. There is no output schema, so the explicit return format is critical and provided. The context from sibling tools further clarifies its niche.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool takes no parameters (empty input schema), so parameter explanations are unnecessary. The baseline for a zero-parameter tool is 4, and the description appropriately provides no redundant parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists the 24 sports offered by Dabble, each with an ID and name. It also explains its role as a lookup for joining sportId from competitions, distinguishing it from sibling tools like dabble_competitions or dabble_active_competitions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: use this to join sportId from a competition back to its sport. It doesn't explicitly mention when not to use it, but the purpose is specific enough that the agent can infer when it's appropriate. No exclusions or alternatives are listed, so it's clear but not exhaustive.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_pre_tournamentA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable context beyond these: it notes the required DATAGOLF_KEY authentication and provides the exact response structure (baseline and baseline_history_fit with field names), which the annotations do not cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: one sentence for purpose, then a returns block and an auth block. It is front-loaded with the primary function and every line provides useful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 explain return values, which it does by listing the exact fields. The tool is simple (no required parameters), and the auth requirement is mentioned. The description is fully adequate for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (tour, file_format, odds_format, add_position) having a clear description including enums and defaults. The tool description does not add any parameter semantics, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that this tool provides pre-tournament model predictions with win, top-5/10/20, and make-cut probabilities per player. This is a specific verb+resource (predictions) and distinguishes from sibling archive tools by focusing on current pre-tournament data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context (pre-tournament predictions) and a prerequisite (DATAGOLF_KEY), but does not explicitly mention alternatives or when not to use it. It lacks the explicit contrast seen in the highest-scoring examples, but is not misleading.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• datagolf_skill_ratingsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses the exact return payload structure and the authentication requirement (DATAGOLF_KEY). This adds meaningful operational context that the annotations do not cover, and there is 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences: purpose, return structure, and auth. The most important information is front-loaded and every sentence adds value with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with no required parameters, the description covers scope, return shape, and authentication. Even without an output schema, the example return structure is sufficient for an agent to understand the tool's behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptive entries for both parameters (display and file_format). The description does not add any parameter-specific detail beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it provides player skill ratings with specific strokes-gained components (off-tee, approach, around-green, putting) and driving accuracy/distance. This is specific and distinguishes it from sibling tools like datagolf_rankings or datagolf_approach_skill.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description establishes a clear context for use — obtaining player skill ratings with detailed breakdowns. It does not explicitly mention alternatives or exclusions, but the scope is evident from the content. Sibling tools like datagolf_rankings are not referenced, so no when-to-use comparison is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_everythingA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Despite annotations indicating readOnly/idempotent, the description adds critical behavioral context: it is undocumented, returns a very large payload (~4 MB), lists the exact return keys, and explains auth requirements (works without key, cookie unlocks more). This goes well 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is somewhat lengthy but every line carries useful information: the mega-view contents, size warning, return keys, example, and auth note. It is front-loaded with the most important warning, though it could be tightened slightly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is quite complete for a tool with no output schema: it lists return keys, size, auth, and an example. However, it doesn't explain the structure of each returned section or how they relate to the targeted sibling tools, leaving minor gaps for an agent deciding between this and alternatives.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all parameters fully. The description does not add significant parameter semantics beyond the example call, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it's a mega-view returning settings, teams, rosters, schedule, draft, and the player pool in one response. The verb 'mega-view' and enumeration of contents distinguishes it from targeted sibling tools like espnfantasy_league_settings or espnfantasy_rosters.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly warns that the response is very large (multi-MB) and advises to prefer a targeted tool unless everything is genuinely needed. This provides clear context for when to choose this tool over alternatives, and the auth note adds usage nuance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_leagueA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it as read-only, open-world, and idempotent, and the description adds auth requirements ('works without a key; ESPN_FANTASY_COOKIE unlocks more') and return structure. It does not contradict annotations and provides additional useful context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with clear sections (purpose, returns, example, auth, fallback). It is a bit long but each part adds value—no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a generic raw read tool, it covers purpose, usage, authentication, and an example. It doesn't mention pagination or rate limits, but given the tool's nature, it strikes a good balance.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all parameters (100% coverage), and the description adds a concrete example that clarifies the 'view' array semantics and how to combine views in one call. This goes beyond the schema's field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Raw league read' with 'ANY combination of views' and positions it as an 'escape hatch' when no dedicated tool fits. It includes an example and distinguishes itself from siblings by being the generic fallback.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says when to use: 'when no dedicated tool below fits, or to fetch several views in one round trip.' Also mentions it can answer queries for other tools (fpl_game_rules, sleeper_league, etc.), providing clear alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_player_cardA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description provides the exact return shape, clarifies that statSourceId 0=actual and 1=projected, includes a complete request example, and discloses authentication behavior (works without key; cookie unlocks more). This adds substantial value beyond the readOnly/idempotent annotations, which are consistent with the described behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized into a purpose statement, return type, example, and auth note. Every section serves a functional purpose, with no redundant filler. The JSON example is compact and aids comprehension. It is longer than a simple two-sentence description but is appropriately detailed for a tool with five parameters and no output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 5 parameters and no output schema, the description compensates by providing a return structure, a full example, and auth context. It explains the meaning of key fields and the filter construction. The description is complete enough for an agent to call the tool effectively without additional documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% description coverage for all 5 parameters. The tool description adds a concrete example that demonstrates how to construct fantasy_filter, including the 'additionalValue' logic ('00'+season actual, '10'+season projected). This enriches parameter understanding beyond the schema's static descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly defines the tool as a 'Deep card for specific players' with full season and per-period stat splits and projections. It identifies the resource (player card) and scope (specific players), which distinguishes it from list-oriented sibling tools like espnfantasy_players. Although no explicit verb is used, the noun phrase is unambiguous and specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for specific players (as opposed to lists) and provides an example with a single player ID. However, it does not explicitly state when to use this tool over alternatives such as espnfantasy_player_info or espnfantasy_players, nor does it state when not to use it. Usage guidance is thus implied but not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_player_newsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the description need not re-state safety. It adds valuable behavioral context: the return structure (news feed with fields), auth behavior ('works without a key; ESPN_FANTASY_COOKIE unlocks more'), and the example input. This goes beyond the annotations without contradicting them, though it does not detail rate limits or pagination behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is efficiently organized: one-sentence purpose, a compact return schema, an example, and an auth note. No filler or redundancy; every segment earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given only 2 parameters, no output schema, and rich annotations, this description is complete. It covers purpose, usage, parameters (via example and source context), return format, and auth. The safety profile is handled by annotations, and the remaining operational details are addressed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers both params with descriptions (100% coverage). The description adds an example ({"game": "ffl", "playerId": 3139477}) and clarifies playerId as 'from espnfantasy_players or a roster entry' (schema says 'ESPN player id'). These additions provide practical context beyond the schema, but the schema already carries most semantic weight.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it provides 'Recent fantasy news items for one player' with a specific focus on 'injury/usage blurbs that drive start-sit calls.' This is a specific verb+resource+scope that distinguishes it from general news tools like espn_news and other espnfantasy tools. The mention of 'one player' specifies the resource granularity precisely.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case (getting player-specific fantasy news for start-sit decisions) and includes an example call. It does not explicitly name alternatives or provide 'when not to use' guidance, but the single-player scope makes the usage context clear. Lacks explicit exclusion such as 'for team-wide news use espn_news instead.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_positional_ratingsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint and idempotentHint annotations, the description adds crucial behavioral details: the exact return structure, the odd non-error behavior on old seasons (absent block), and authentication requirements. This gives the agent confidence in interpreting unexpected responses.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is organized into clear sections (definition, return type, in-season caveat, example, auth). Each section is informative, but the example is questionable and the return structure line is dense. Slightly verbose but no wasted words, justifying a 4.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of an output schema, the description compensates by providing the full return structure, a scenario for when it fails, and auth info. However, the misleading example and lack of clarification about position IDs (e.g., what '1' means) leave minor gaps. Overall highly complete, so a 4.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already has 100% coverage with descriptions for all parameters, so the baseline is 3. The description adds value through a concrete usage example (though the seasonId is problematic) and clarifies the default game 'ffl' implicitly. This nudges the score to 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: it returns average fantasy points allowed by each pro defense to each position, explicitly calling it the strength-of-matchup table. This is a specific verb+resource+scope that distinguishes it from sibling tools like espnfantasy_players or espnfantasy_standings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: it is 'IN-SEASON ONLY' and explains what happens with completed/old seasons (200 with absent block, not an error). It also includes an example with parameter values. However, the example uses seasonId 2018, which contradicts the in-season-only warning since 2018 is a completed season, potentially leading an agent astray.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espn_standingsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and open-world behavior. The description adds the exact return structure, explains that children represent conferences/divisions, and notes 'Auth: none needed.' This adds meaningful context beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, containing only three short sections: purpose, return structure, and example/auth note. Every sentence provides value with no repetition or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only standings tool, the description covers purpose, return shape, parameter example, and authentication. Given the complete input schema and annotations, nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents all parameters with descriptions. The description supplements this with a concrete example showing sport='basketball' and league='nba', and clarifies that season is optional (current or given). This adds practical usage guidance beyond the schema fields.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description explicitly states 'League standings / ladder: per-team wins, losses, win %, conference/division groupings' and provides an example for NBA. This clearly defines the tool's function and distinguishes it from sibling ESPN tools like espn_scoreboard or espn_game_summary.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear usage context by indicating 'for the current (or a given) season' and giving an example call with sport and league. It does not explicitly list alternatives or exclusions, but the generic sport/league parameters make its scope obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• euroleague_game_statsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Even with annotations (readOnlyHint, idempotentHint, openWorldHint), the description goes well beyond them. It explains the nested structure (player vs stats), defines 'valuation' as EuroLeague's PIR metric, and warns that 'timePlayed' is in seconds as a float (e.g., 1088.0 = 18:08), not a MM:SS string. It also explicitly states 'Auth: none needed,' covering a behavioral aspect not evident from annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence carries useful information: the result structure, nesting, unit conventions, metric explanation, an example call, and auth requirements. It is front-loaded with the core purpose and structured with a clear 'Returns:' block. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with a complex nested return object and no output schema, the description fully compensates by detailing the return structure, the meaning of specific fields, and the required inputs. It includes an example to illustrate correct invocation. This gives an agent everything needed to select and call the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already has 100% description coverage, with each parameter (season, gameCode, competition) clearly documented. The description adds a concrete example using actual values, but it does not provide additional semantic meaning beyond the schema. The example is helpful but not necessary for understanding what each parameter does.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Box score for one game: both teams' player lines plus team totals and coach.' It clearly distinguishes this tool from siblings like euroleague_game or euroleague_games by focusing on per-game detailed statistics. The return structure is fully specified, leaving no ambiguity about what is returned.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates the tool is for retrieving a box score for a specific game, and the example shows the required parameters. It implies use when you need detailed player and team stats, but it does not explicitly state when not to use it or name alternative tools for other purposes (e.g., schedule or list of games). Thus, it provides clear context but no explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• formulae_championshipsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds meaningful context beyond annotations: the exact return shape, status enum values, the 'lastFinishedRound' field, the nested series object, and an explicit auth requirement. This enriches what the agent can expect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: first the core purpose and sequencing, then the return format, a brief example, and auth status. Every sentence serves a purpose with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only listing endpoint with rich annotations, the description is complete. It includes the return structure, status enum, example, auth note, and the crucial 'call this first' guidance. No output schema exists, so the description appropriately carries the return-format responsibility.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline of 4 applies. The description does not need to add parameter details, and it does not introduce any confusion about inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns every Formula E season with its UUID, establishing a specific purpose and resource. The phrase 'call this first, everything else needs the id' distinguishes it from sibling Formula E tools like formulae_races and formulae_race.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit sequencing guidance: 'call this first, everything else needs the id.' It also confirms no auth is needed, which helps the agent decide when to call it. It does not name specific alternative tools or exclusions, but for a zero-parameter root endpoint this is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_dream_teamA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds valuable behavioral context: return payload structure, 404 error semantics until gameweek finishes, and authentication behavior (works without key, FPL_SESSION_COOKIE unlocks more). This exceeds what structured data provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Compact and well-structured: one-sentence purpose, Returns block, Example, Auth. Every line adds unique information with no fluff. Front-loaded with the key concept before details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one parameter and no output schema, the description provides everything needed: purpose, exact return format, error condition, example, and auth. It fully compensates for missing output schema by listing fields. No gaps identified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter 'gameweek' is fully documented in the schema (100% coverage) including type, requirement, and error behavior. The description only adds a usage example, which is helpful but not essential; baseline of 3 applies when schema carries the semantic weight.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states resource ('highest-scoring XI of a completed gameweek') with specific detail. Distinguishes from siblings like fpl_live_gameweek and fpl_gameweeks by focusing on the final dream team XI per gameweek. Includes return shape, reinforcing purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Gives explicit context that the tool requires a COMPLETED gameweek and 404s on unfinished ones, establishing a clear when-not-to-use. Doesn't name alternative tools (e.g., fpl_live_gameweek for live scoring), but the exclusionary timing guidance is strong.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_fixturesA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/openWorld/idempotent annotations, the description explains key behavioral nuances: stats are empty until the match is played, difficulty ratings are per side, finished_provisional precedes finished with non-final bonus points, and auth behavior is disclosed. This is rich, non-redundant context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with purpose, then provides a structured return shape, a concrete example, and auth note. Every sentence earns its place, with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 carries the full burden of explaining the return value, lifecycle states, and auth. It does so completely enough for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema already covers both parameters with 100% description coverage. The description's example reinforces event filtering but does not add material semantic meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening sentence precisely identifies the resource: 'Fixtures with FPL difficulty ratings, and goal/assist/bonus breakdowns once played.' The example and return-shape detail make it unambiguous that this is the FPL fixture tool, distinguishing it from siblings like fpl_gameweeks and fpl_player_detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the use case clear via the resource, the 'Example: One gameweek's fixtures {"event":1}' snippet, and schema hints for filtering. It does not explicitly name alternatives or say when not to use it, so it falls short of a 5, but the context is sufficiently clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_player_detailA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable behavioral context: auth requirements ('works without a key; FPL_SESSION_COOKIE unlocks more'), the meaning of difficulty, and that value represents gameweek-level price. It doesn't cover every edge case but does well given 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, then provides a compactly formatted return structure, field clarifications, an example, and auth note. Every sentence earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 specifies the three return sections and their key fields. It explains the difficulty scale and price semantics, making the tool usable for FPL analysis directly from the description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and already explains playerId source and URL path. The description adds a concrete example (playerId: 1) and reinforces that it refers to a full player record. This exceeds the baseline for a high-coverage schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'One player in full' and enumerates exactly what is returned: every gameweek this season, past seasons, and upcoming fixtures with difficulty. This clearly distinguishes it from list-level tools like fpl_players or simpler per-player tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use this tool: when you need a comprehensive player record including fixtures and history. It does not explicitly name alternatives or exclusions, but the scoping language makes the intended use obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• jolpicaf1_driversA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints, so the description only needs to add context beyond that. It does so by showing the exact return structure, explaining the significance of `driverId`, providing a request example, and noting auth is not needed. This goes beyond a minimal read-only disclosure, though it does not cover pagination behavior (which is left to the schema).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a brief scope statement, the return payload, a key clarification about `driverId`, an example, and an auth note. Every sentence contributes useful information without redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even though there is no output schema, the description provides the return structure explicitly. It covers auth, an example, and the critical relationship to other tools. With four parameters all documented in the schema and simple read-only semantics, this is a complete description for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all parameters with descriptions, so the baseline is 3. The description adds semantic value by explaining that `season` can mean 'all-time' or 'the field for one season' and by showing a concrete example with `season` and `format`. This clarifies the parameter's role beyond what the schema alone provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'Drivers' and specifies the dual scope: all-time or a single season's field. It also highlights the critical `driverId` field and its role as the key for other tools, distinguishing this from sibling F1 data tools like results or standings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use this tool: to obtain driver details and the `driverId` that other tools filter on. It gives an explicit example of the `season` parameter. However, it does not explicitly name alternative tools or state when not to use this tool, so it earns a 4 rather than a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• laliga_matchA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only and idempotent, so the description adds conditional data behavior (scores/formations only for played matches) and auth context (works without key, subscription key unlocks more). This adds meaningful value 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: purpose, returns, and auth in separate sections. Every sentence contributes, with no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter tool with no output schema, the description covers purpose, slug source, result fields, conditional behavior, and auth. The explicit Returns list effectively substitutes for an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers the slug parameter with origin guidance, but the description adds critical nuance about the slug format (long temporada slug vs. numeric id) and a 404 pitfall, going beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves one match by SLUG, referencing laliga_matches as the source and distinguishing from plural list tools. It also specifies what data is returned (scores + formations for played matches).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit guidance on where the slug comes from (laliga_matches) and warns against using the numeric id which 404s. However, it does not directly compare with alternative match-detail tools or state when not to use it, though that is implied by 'One match'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lichess_tournamentsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as read-only, open-world, and idempotent. The description adds value by detailing the exact return shape (three lists by state, not one) and noting that no authentication is required, which goes beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-line purpose, a returns section with exact field names, an example, and an auth note. Every sentence serves a purpose with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no params, no output schema), the description is complete. It explains what the tool returns, the structure of each list, the states, and authentication, covering all necessary information for an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has no parameters, so the description doesn't need to explain input semantics. It correctly omits any parameter details, and the baseline for zero-parameter tools is 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns Arena tournaments in three states (currently running, finished, upcoming) and explicitly provides the return structure. This distinguishes it from other Lichess tools like user or leaderboard endpoints, so an agent can easily identify its purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use this tool: to fetch all arena tournaments across states. It provides an example and notes auth is not needed, but it doesn't explicitly mention alternatives or conditions when not to use it, making it clear but not exhaustive.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lichess_userA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context beyond annotations: 'Auth: none needed' and the caveat that there is no single 'rating' field, but perfs.<timeControl>.rating. It does not duplicate annotation info, and no contradictions exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized: a brief purpose statement, a detailed but justified return structure, a clear example, and a short auth note. Every sentence serves a purpose, and it is front-loaded with the core intent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter read-only tool, the description is thoroughly complete. It provides the entire return shape, a concrete example, an auth note, and an important caveat about accessing ratings. This compensates for the absence of an output schema and gives the agent everything needed to invoke and interpret the result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully documents the 'username' parameter (required, case-insensitive, part of URL path). The description adds a concrete example ('thibault'), which helps the agent understand expected input beyond the schema description. This exceeds the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as retrieving a single Lichess player's data: ratings per time control, games played, play time, and profile. The 'Returns:' section and example ('One player's profile and ratings') unambiguously define the purpose, and it is distinct from sibling tools like lichess_leaderboard or lichess_users_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage via the example and the required 'username' parameter: use when you need a specific player's profile. It provides clear context (single-player lookup) but does not explicitly mention alternatives or when-not-to-use scenarios, which would earn a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_available_groupsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, which cover the safety and side-effect profile. The description adds value by specifying what is listed (tool groups and auth requirements) and the special fresh-install behavior, complementing the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with zero filler. The first sentence states the purpose precisely, and the second provides essential operational context. Every word contributes meaning, and the structure is front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with a rich output schema and clear annotations, the description fully explains what the tool does and when it is particularly useful. It covers the essential context without being verbose, so nothing important is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and schema coverage is 100% (trivially). With no parameters, the baseline is 4 per the rubric. The description does not need to add parameter details and does not attempt to, so this score is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'List every tool group across all providers, which are currently enabled, and each provider's auth requirements', which is a specific verb+resource+scope. This clearly distinguishes it from sibling tools like list_tools_by_capability that focus on capabilities rather than enabled groups and auth needs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete use case: 'On a fresh install (no groups enabled) this is the only functional tool, so the model can guide the user to enable what they want in sportsdata-mcp.yaml.' This implies when to use the tool, though it does not explicitly contrast with alternatives or state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_metaA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, idempotent, and open-world hints. The description adds valuable context about return shape ('shape depends on type; e.g. positions → [{code, name, type, abbrev}]') and states no auth is needed. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four short sentences, front-loaded with purpose, and includes return shape and auth. Every sentence earns its place with no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite being a simple one-parameter tool with no output schema, the description includes purpose, usage, return shape, and auth. It fully supports an agent selecting and invoking the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully covers the 'type' parameter with an enum and description. The description adds meaning by explaining that 'type' is part of the URL path and that the return shape varies by type, with a concrete example. This goes beyond the schema's enum listing.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches valid values for parameters used elsewhere (stat types, positions, game types, pitch codes, etc.). The phrase 'One tool over the API's /{type} endpoint' distinguishes it from sibling MLB tools that fetch specific data rather than lookup tables.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use: when you need to know valid values for a parameter before calling other tools. It establishes its role as a meta-lookup tool, but it does not explicitly list alternatives or exclusions, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_seasons_allA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only/idempotent behavior. The description adds valuable context: auth not needed, full historical scope (151+), and a concrete return shape. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose. Every sentence serves a purpose: scope, sibling distinction, return shape, and auth. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only catalogue with optional filters, this description is complete. It includes the API endpoint identity, return schema, auth info, and the key differentiator from the sibling tool. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 three parameters (sportId, leagueId, divisionId) with clear descriptions. The tool description adds no additional parameter-level meaning, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists every MLB season with key dates (151+), and explicitly distinguishes it from the plain /seasons endpoint that returns only the current season. This makes the purpose and scope unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit comparison to the sibling tool: 'Plain /seasons only returns the current season; an ?all=true query there is a no-op.' This tells the agent exactly when to choose this tool over the alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mlb_teams_statsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety. The description adds 'Auth: none needed' and explicitly shows the return shape '{stats:[...]}', which provides useful behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose, followed by return format and auth requirement. Every sentence earns its place; no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description supplies a return shape. Combined with the highly descriptive parameter schema and read-only annotations, it gives the agent everything needed to understand when and how to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds meaning by clarifying 'season + group' for filtering and 'Sort + limit for top-N' for sortStat/limit, which enriches the bare schema definitions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses specific language: 'Aggregate stats across all teams' and 'league-wide team leaderboard by season + group.' It clearly distinguishes itself from team-specific tools like mlb_team_stats by emphasizing the aggregate, league-wide scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly implies its use case: retrieving aggregate team statistics for a given season and group, with sorting and limiting. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to differentiate from team-specific or player-specific stat tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• mysportsfeeds_boxscoreA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety is covered. The description adds valuable behavioral context: the return shape is from vendor docs and unverified, the agent should inspect the actual payload, and the tool requires an API key in MYSPORTSFEEDS_API_KEY. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections: purpose, return shape, caveat, example, and auth. It is slightly long due to the detailed return shape, but every section carries necessary information, and the main purpose is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description provides a detailed return shape approximation, a usage example, auth requirements, and a critical caveat about the unverified payload. It doesn't cover season format details or playerstats value options, but those are partially in the schema, and the overall picture is solid.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 goes beyond the schema by explaining the convenient game id form '20240115-LAL-BOS' and including a full example mapping league, season, and game. It doesn't add detail for playerstats, but the schema already describes it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening line 'Full box score for one game, team and player level' is a specific verb+resource+scope. It clearly distinguishes this tool from sibling tools like mysportsfeeds_games, mysportsfeeds_player_gamelogs, and other league-specific boxscore tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly states the tool is for a single game's box score and provides a concrete usage example. It gives guidance on the game id format (date-team string), but doesn't explicitly name alternatives or exclusions relative to sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nba_odds_todayA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints. The description goes beyond by clarifying the live CDN data source, noting that no authentication is needed, and providing a return structure. These are useful behavioral details not present in 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded. The first sentence conveys the core purpose, followed by a concise return structure and a note on authentication. Every sentence serves a purpose without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple no-parameter read-only tool with strong annotations, the description is complete. It states the data source, the odds types, the return structure, and auth requirements. There is no output schema, so the provided return shape compensates well. Minor ambiguities like timezone are not critical given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description adds no parameter information because there are none, but it does explain the output granularity (per game and book), which indirectly helps understand the data shape.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides sportsbook odds for today's NBA games from a live CDN feed, specifying the odds types (spread, money line, total). This is specific and distinguishes it from sibling tools that cover other sports or generic odds APIs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context that this tool is for today's NBA odds, and the example 'Today's game odds' reinforces the intended use case. However, it does not explicitly mention alternatives or when not to use it, so it misses the 'when-not' guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nba_stats_callA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds valuable behavioral detail beyond the annotations: it discloses the column-oriented response format ({resultSets:[{name, headers, rowSet}]}) and instructs to zip headers with rows. It also notes that no auth is needed and that guessing an operation returns an error (in the schema description). This enriches the agent's understanding of how the tool behaves.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact yet information-dense. It front-loads the purpose, then covers usage guidance, resource reference, response format, and authentication in a logical flow. Every sentence earns its place; there is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool that wraps 138 possible operations, the description is remarkably complete. It covers invocation, default param behavior, where to browse operations, the common response shape, and auth requirements. It appropriately points to the catalogue resource for operation-specific details, so the agent knows where to look for the rest. The presence of rich annotations and full schema descriptions further complements this.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 meaningfully adds to the schema: it explains that operation is a '/stats/ path segment' and that query_params overrides the pre-loaded default parameter set, giving a concrete example ({Season: '2024-25', PlayerID: '201939'}). This goes beyond the schema's generic descriptions and helps the agent construct correct calls.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Gateway to the stats.nba.com /stats/ analytics API (138 operations)', giving a clear verb ('Gateway') and specific resource. It lists concrete operation examples (e.g., 'leaguedashplayerstats', 'shotchartdetail') that are distinct from the sibling NBA-specific tools, making its role as a raw API gateway unambiguous. Though it doesn't explicitly say 'use this instead of balldontlie_nba_stats', the specificity of the resource and operations differentiates it well.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description tells the user exactly what to supply (operation and query_params), explains that each operation has NBA's full default param set and only overrides are needed, and directs to the nba://stats/operations resource for full details. It doesn't explicitly name alternative tools or exclusion criteria, but the usage context is clear and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_season_currentA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only/idempotent safety, but the description adds valuable behavior: it may return empty in the deep off-season yet still resolve, and includes the exact return shape. It also states auth is not needed. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the main purpose. Every sentence contributes: purpose, shortcut relationship, off-season caveat, limit usage, return shape, and auth. No filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read tool with one optional parameter and no output schema, the description is fully adequate. It includes return structure, edge-case behavior, and auth info. No significant gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents the single `limit` parameter (default 1, max rows). The description repeats this via 'Use `limit` to cap rows' without adding new meaning, so baseline 3 for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this tool returns current season(s) and explicitly positions it as a convenience shortcut over nbl_seasons, distinguishing it from that sibling. The verb and resource are specific, and the off-season behavior is noted.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Names nbl_seasons as the broader tool this shortcuts, and warns that results may be empty in the deep off-season, which provides practical context for when this tool is appropriate. The mention of the `limit` parameter also aids usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_seasonsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds value by disclosing that no auth is needed, the exact return structure, and the scope ('Every NBL season'), which goes beyond the annotations. No contradictions found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and concise, with every sentence providing useful information: the scope of data, the downstream tool connections, the current-season heuristic, the return format, and auth requirements. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter discovery tool, the description is complete. It includes the full return schema, gives practical usage guidance, notes auth requirements, and even explains how to derive the current regular season. The absence of an output schema is fully compensated by the explicit 'Returns' section.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  This tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, but it does explain the output fields in detail, which adds semantic meaning beyond the empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: it returns every NBL season with all relevant fields. It also positions itself as the discovery entry point, linking to downstream tools like nbl_stat_leaders and year-scoped feeds, which distinguishes it from sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use this tool: to get a season's id for nbl_stat_leaders or its year for year-scoped feeds, and how to identify the current regular season. It lacks explicit exclusions or alternative tool comparisons, but the guidance is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_teamsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, open-world, and idempotent behaviors. The description adds value by specifying the return structure, noting that it includes historical/relocated franchises, and stating that no auth is needed. This is sufficient for a zero-parameter catalogue tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a clear one-sentence overview, a formatted return shape, and an auth note. No unnecessary details; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple zero-parameter catalogue tool with rich annotations, the description is complete. It covers what the tool returns, how to relate it to other NBL data, and authentication requirements. The included return shape compensates for the lack of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters, so the description does not need to add parameter semantics. The empty input schema is fully covered by the description (schema coverage 100%). The description correctly implies this is an unfiltered list of all teams.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies this as the NBL club catalogue, listing teams with their IDs, names, codes, logos, and colors. It explicitly specifies the scope (~78 incl. historical/relocated franchises) and differentiates it from related tools by mentioning the join keys from nbl_players/nbl_schedule.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context on when to use this tool: to join team_id from nbl_players/nbl_schedule to team details. It implies using this when you need team metadata, but does not explicitly state when not to use it or name alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nhl_seasonsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds value by disclosing the response structure (currentDate, seasons array with specific fields), the season id format, and that auth is not needed. It doesn't mention pagination or limitations, but for a no-parameter list endpoint, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and structured: purpose statement, return example, and auth note. It front-loads the key action (get valid season ids) and includes a clear return format example. No redundant text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-output-schema tool, the description is complete. It explains what data is returned, the format of the important id field, and that no auth is needed. It provides enough context for an agent to call it and correctly use the response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters, so the baseline is 4. The description goes beyond schema by explaining each field in the return object and what the season id represents. It fully compensates for lack of input parameters by describing the output semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: 'Every season the standings API covers, with its start/end dates and which rules applied — call this to get valid season ids.' It specifies a concrete verb+resource and distinguishes itself by providing season metadata and IDs for other tools. The return example further clarifies the exact purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells the agent when to use this tool: 'call this to get valid season ids' and notes that the id format is what 'every other tool wants.' This implies using it as a prerequisite for other NHL tools. It lacks explicit 'when not to use' or alternatives, but the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nrl_application_settingsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds value by disclosing the return shape ({applicationInfo, userInfo, competitionList, components, dataGrids, shellGroups}) and explicitly stating 'Auth: none needed.' This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: it names the resource, lists key contents, provides a use case, gives the return shape, and notes auth requirements in just a few lines. Every sentence provides useful information with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no parameters and no output schema, the description is remarkably complete. It specifies the return object's fields, highlights the practical use case, and confirms no authentication is required. The 'Example' line reinforces the purpose without adding unnecessary bulk.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the input schema is an empty object, so schema coverage is trivially 100%. Per the rubric, 0 params earns a baseline of 4. The description adds no parameter details, but none are needed; it clearly references the current-season dynamic nature of the returned config.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this is 'NRL match-centre application config' and enumerates the contents (competitionList, dataGrids, UI components, image paths). It differentiates from sibling tools like nrl_competitions by focusing on configuration data rather than match data, and adds a concrete use case: discovering active competitionIds and surfaced statistics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear context for when to use this tool: 'Handy for discovering the active competitionIds and which statistics the official site surfaces.' This implies it is for configuration lookup rather than live match data, but it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opendota_hero_statsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description goes further by explaining the return structure, skill bracket prefixes (1-8), and the win-rate calculation, which are not available in annotations or schema. It also notes 'Auth: none needed.'

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tightly packed: a one-sentence summary, a structured return format, an example, and an auth note. Every line adds value, and the field explanation is front-loaded. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no parameters and no output schema, the description carries the full burden of explaining the response. It fully documents the field names, meaning, and calculation, and even provides an example. The tool is simple, and the description covers all necessary aspects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so no parameter explanation is needed. Baseline is 4 per the rubric. The description focuses on the output fields, which is appropriate for a parameterless tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb+resource: 'Per-hero win and pick counts broken down by skill bracket.' It clearly states what data the tool returns and distinguishes it from sibling tools like opendota_heroes, which likely provide basic hero info, by focusing on meta stats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'the hero meta' implies it is the go-to for hero performance analysis, and the example adds practical context. However, it does not explicitly contrast with alternatives or provide when-not-to-use guidance, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opendota_leaguesA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint/idempotentHint/openWorldHint annotations, the description adds valuable behavioral context: the response is LARGE (~1 MB), includes historical events, returns a specific structure, and requires no authentication. This enriches the agent's understanding of response size and field formats without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the core purpose. It packs essential details (size, return fields, example, auth) into a few well-organized lines without any redundancy. Every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, no-parameter read-only list tool, the description is complete: it covers the data scope, size warning, return schema, example usage, and authentication. There is no output schema to rely on, so these details are essential and provided clearly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema coverage is vacuously 100%. The description compensates by explaining that filtering is done client-side (since no server-side filter parameters exist), which clarifies why there are no inputs. This goes beyond the baseline expectation for a no-parameter tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states exactly what the tool does: it returns every Dota 2 league/tournament known to OpenDota. The verb 'Returns' and specific resource ('league/tournament') are clear, and it distinguishes itself from sibling OpenDota tools by covering the complete set of leagues.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool (when you need all leagues/tournaments) and even advises to filter client-side by tier. It does not explicitly name alternatives or exclusions, so it doesn't reach a 5, but the guidance is solid for a simple list tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openf1_meetingsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds valuable context beyond these: the return format (field list, top-level array), the special 'latest' value, and the fact that auth is not needed. This goes beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the tool's purpose, then filters, then return format and auth. No redundant or irrelevant information; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description lists all return fields and notes the top-level array. It covers auth, filter options, and the special 'latest' case. For a simple read-only listing tool, this is complete and self-sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for all four parameters. The description enriches the parameter semantics by clarifying that year and country_name are filters, and by revealing the special 'latest' value for meeting_key. This is beyond the schema's basic parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource as 'Grand Prix weekends (meetings)' and explains filtering by year/country or using meeting_key=latest. This distinguishes it from sibling tools like openf1_sessions and openf1_drivers by focusing specifically on meeting-level data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives practical usage instructions: filter by year/country or pass meeting_key=latest for the current event. While it doesn't explicitly mention alternatives like openf1_sessions, the scope is clear enough for an agent to know when to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openligadb_current_matchdayA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable behavioral details beyond that: the return shape ('a single object, not a list'), the exact fields returned, an example response, and an explicit 'Auth: none needed.' This contextualizes what to expect from the call.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: starts with purpose, then return type, then a concrete example, then auth note. Every line earns its place, with no redundant or vague language.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one optional parameter, no output schema), the description is complete: it explains what the tool does, when to use it, the exact parameter format, the return structure, and auth requirements. No significant information is missing for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage with a description and default for the 'league' parameter. The description reinforces the semantics by showing a concrete usage example ('{"league": "bl1"}' for Bundesliga), which adds clarity beyond the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Which matchday a league is currently on' and adds practical context ('resolve this week without guessing'). It distinguishes itself from siblings like openligadb_matchdays (list all matchdays) and openligadb_matchday_matches by focusing on the current matchday as a single object.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context for when to use the tool (need the current matchday, e.g., to resolve 'this week'), and includes a concrete example for Bundesliga. However, it does not explicitly name alternative tools or exclusion criteria, so it falls just short of full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openligadb_leaguesA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only/idempotent/open-world behavior, and the description adds meaningful context: the exact return shape, estimated size (~819 entries, ~120 KB), an example, and that no auth is needed. This goes beyond the annotations' basic safety hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: it states the purpose in the first line, then provides a concise return example, size estimate, and auth note. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter read-only tool, the description is thorough: it covers what is returned, gives an example, notes size, and states auth requirements. Without an output schema, it provides enough detail for an agent to understand and consume the result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so the baseline is 4. The description adds semantic clarity by showing the output fields like leagueShortcut and leagueSeason, which is useful for downstream tool usage, even though no parameter-specific details are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'every competition + season OpenLigaDB carries' and explicitly frames its purpose: to 'find the league shortcut and season year the other tools need.' This is a specific verb+resource (list leagues/seasons) and directly distinguishes it from sibling tools that consume these identifiers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description says to call this when you need the league shortcut and season year for other tools, providing clear usage context. It does not explicitly list when not to use it or name alternative sources, but the intended sequencing is evident from the dependency it highlights.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openligadb_matchday_matchesA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context beyond these: auth is not needed, the return shape matches openligadb_season_matches, and typical size (~9 matches). This gives the agent a clear behavioral model without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tight and front-loaded with the core purpose, then follows with return shape, an example, and auth note. No redundancy or filler—every sentence contributes to understanding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even though there's no output schema, the description adequately explains the return shape by referencing openligadb_season_matches, and the example provides an input pattern. Combined with the annotations covering safety and idempotency, this is complete for a simple, read-only, single-matchday lookup.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for all three parameters, so the baseline is 3. The description adds a concrete, complete example that clarifies the season format as a string ('2024') and shows the league default in action, which goes slightly beyond the schema's generic descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'One matchday's fixtures and results' and immediately differentiates it from the sibling openligadb_season_matches by noting 'restricted to one matchday'. The verb 'Returns' and resource are specific, and the example further confirms the exact purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context by calling this 'the everyday call' and specifying it handles one matchday, indirectly distinguishing it from season-wide tools. However, it stops short of explicitly saying 'use openligadb_season_matches for multiple matchdays', so there's no formal exclusion but the intended use case is evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pandascore_matchesA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds significant context beyond the annotations: it discloses the return shape (top-level array, X-Total header), warns that the shape is from vendor docs and not verified against live responses, and notes the auth requirement (PANDASCORE_TOKEN). It also highlights a subtle field wrapping ('opponents' wraps teams under 'opponent' key). This is far more than annotations alone provide and is honest about reliability.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with purpose, and every sentence contributes value: the return shape, the unverified caveat, the example, and the auth note. There is no fluff or redundancy; the warning about vendor docs is especially useful and concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description compensates by providing a detailed return shape, pagination header info, filterable statuses, an example, auth requirements, and a reliability caveat. It covers what the agent needs to select and invoke the tool correctly, including how to interpret the response and what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description's example demonstrates how to combine filter_videogame and filter_status, but it doesn't add meaning beyond the schema (the schema already explains 'csgo' is a title slug). The parameter descriptions in the schema are sufficient, and the example is more of a usage guideline than parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Matches across every title, or one — upcoming, running or past', which clearly identifies the resource (matches), the scope (all titles or one) and status filter. It distinguishes itself from sibling pandascore tools (e.g., pandascore_videogames, pandascore_tournaments) by focusing specifically on match listings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The example 'Upcoming CS2 matches' with filter_videogame and filter_status provides a concrete use-case, and the description states it can return matches across all titles or a single one. However, it does not explicitly mention when to use this tool versus related alternatives like pandascore_match_odds or other sports match endpoints, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinnacle_carouselA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, idempotent, and open-world behavior. The description adds the return shape (array of objects with id, league, participants, startTime, hasMarkets, hasLive) and explicitly notes that no authentication is needed, providing useful behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise: one sentence for purpose, one line for return format, and one for auth. All information is front-loaded and every sentence adds value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only endpoint, the description is complete: it states what the tool returns, the data shape, scope, and authentication requirements. The annotations cover safety and idempotency, so no additional behavioral disclosure is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema is empty, so there is nothing for the description to clarify. Per the rubric, a baseline of 4 applies when there are no parameters, and the description correctly does not fabricate parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as returning a featured matchups carousel across all sports, specifically for homepage highlights. This distinguishes it from sibling tools like pinnacle_sport_matchups or pinnacle_league_matchups by indicating it is a curated, cross-sport highlight feed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear use case (homepage highlights) and scope (all sports), but does not explicitly name alternative tools or state when not to use it. Still, the 'homepage highlights' context gives adequate guidance for selecting this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_countryA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds useful context beyond the annotations: it explicitly states 'Auth: none needed' and describes the return value. Since annotations already declare read-only, idempotent, and open-world traits, the bar for additional disclosure is lower, and this description meets it by covering auth requirements and output shape.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, using a few short lines to convey purpose, return value, and authentication. Every sentence earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no parameters, no output schema, and a simple purpose, the description is fully complete. It explains what the tool does, why it exists, what it returns, and that no auth is needed. No additional context is required.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so the baseline for this dimension is 4. The description doesn't need to explain parameters, and it goes beyond by mentioning the return format ({country}), providing semantic meaning where the schema is empty.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('Echoes') and resource ('caller's detected country'), and explains its purpose ('used by the site for content geo-gating'). This distinguishes it from sibling PL tools, which focus on competitions, teams, matches, etc.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool (i.e., to determine the caller's country for geo-gating), but does not explicitly mention alternatives or exclusion criteria. Given the unique function compared to siblings, the implied usage is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_team_next_fixtureA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint annotation, the description discloses the 404 error behavior for off-season, the exact return fields, and that no authentication is needed. These are valuable behavioral traits not covered by annotations and improve the agent's ability to handle responses correctly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is efficiently structured with a one-sentence purpose, a return shape line, and an auth note. Every sentence adds value with no redundancy, making it easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple fixture lookup with three clear parameters and no output schema, the description covers the purpose, the 404 edge case, the response shape, and auth requirements. It is complete enough for an agent to understand what the tool returns and how to handle errors.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents all three required parameters with descriptions and notes they are path parameters (100% schema description coverage). The description does not add parameter-specific details beyond what the schema provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns a team's next scheduled fixture, which is a specific verb+resource combination. This distinguishes it from siblings like pl_matches (all fixtures) and pl_match (a specific match), especially with the 404 note for no scheduled fixture.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it returns the next scheduled fixture for a team, with a 404 when none is scheduled (e.g., off-season). It doesn't explicitly name alternative tools, but the context is sufficient to infer when to use it. No exclusions or when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pointsbet_racing_meetingsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only and idempotent behavior. The description adds value by showing the exact return structure, noting 'auth: none needed', and clarifying the scope ('every code'). It does not mention potential large response sizes or pagination, but the annotations lower the burden; the added details go beyond what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely efficient: two sentences, a return shape, a JSON example, and an auth note. It front-loads the core purpose and includes only necessary details. No wasted text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description includes the full return structure, an example, and auth requirements. For a straightforward read-only listing tool with clear annotations, this is complete. It also distinguishes from siblings well enough for an agent to select it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear ISO-8601 descriptions for both parameters. The description reinforces this with a concrete example using startDate and endDate for a single day, demonstrating the expected format and usage. This adds practical clarity beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists all race meetings (every code) for a date window, with nested races included. It distinguishes itself from sibling tools like 'pointsbet_racing_meeting' (singular) by emphasizing 'all' and the date-window scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear usage context (date window) and an example for 'all meetings for one day', but does not explicitly mention when to prefer this over other racing tools like pointsbet_racing_meeting or pointsbet_racing_races. It implies broad coverage but lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• polymarket_bookA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only, open-world, and idempotent. The description adds that no auth is needed and specifies the exact return shape (market, asset_id, bids, asks, tick_size, neg_risk, timestamp), going beyond the annotation-provided safety profile without contradicting it.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is brief and front-loaded, stating the primary purpose in the first sentence. Return format, auth, and alternative are each given in short, structured lines, with no redundant wording or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description covers the purpose, return structure, auth requirements, and an alternative sibling. This is sufficient for an agent to select and invoke the tool correctly, and the schema handles the parameter detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The sole parameter (token_id) is fully documented in the input schema as 'CLOB token id (one entry of a market's clobTokenIds)', so the schema covers 100% of the parameter semantics. The description does not add additional parameter-specific information beyond restating that it is for one outcome token, matching the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns the full order book (bids and asks with sizes) for one outcome token. It uses specific terms like 'bids', 'asks', and 'sizes', and scopes it to a single outcome token, distinguishing it from other Polymarket tools that return prices or midpoints.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly mentions 'Auth: none needed' as a prerequisite and names 'kalshi_orderbook' as an alternative query it can answer, giving the agent a clear when-to-use signal. This provides direct guidance on when this tool is appropriate compared to a sibling.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• polymarket_eventsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, lowering the burden. The description adds the exact return format, an example query, and notes that no auth is needed. This goes beyond annotations by clarifying the response shape and example usage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured with separate sections for definition, return format, example, and auth. It avoids redundant wording and front-loads the core purpose, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description provides a full return structure and an example request, which compensates for the missing structured output. All 14 parameters are documented in the schema, and the description adds practical usage context, making the tool adequately specified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all 14 parameters with descriptions (100% coverage), providing the baseline. The description adds meaningful context via an example showing how to combine limit, active, closed, order, and ascending, which clarifies typical usage patterns beyond the schema's individual parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly defines the tool as an 'Event catalogue' that groups related markets, distinguishing it from sibling tools like polymarket_markets or polymarket_event. It specifies the return structure with nested markets and provides a concrete example, making the tool's purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context on when to use this tool (to list events with nested markets) and includes a usage example (most-traded active events). It does not explicitly mention alternative tools or exclusion criteria, but the context is sufficient for an agent to infer appropriate usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• seriea_seasonA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, so the read-only nature is covered. The description adds value by disclosing the response structure and confirming 'Auth: none needed', which provides useful operational context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose, and includes return format and auth details with no waste. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only retrieval tool with full schema coverage and enabling annotations, the description covers purpose, usage implication, response shape, and auth. No significant gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both parameters. The description goes further by providing a concrete example for seasonId and pointing to the source tool 'seriea_seasons', adding meaning beyond the schema. Locale does not get extra explanation, but the schema description suffices.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'One season's detail by seasonId' with a specific verb and resource, clearly distinguishing it from the sibling list tool 'seriea_seasons'. The return structure is also outlined, reinforcing the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The seasonId parameter description says 'from seriea_seasons', implying the correct workflow of first listing seasons then fetching details. However, there is no explicit when-not-to-use or alternative comparison, so it is clear but not fully explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sleeper_league_usersA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety. Description adds the return shape, the keying by user_id, and the data model uniqueness, which is useful context beyond structured data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Description is front-loaded with a clear purpose, followed by a compact return type, example, and auth note. Every part adds value and no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given a single parameter, no output schema, and strong annotations, the description fully covers what the tool returns, how to call it, and its unique role in the data model. The example makes it actionable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema already describes league_id as required and part of the URL path with 100% coverage. Description adds an example league_id but doesn't explain semantics beyond the schema; baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool returns league users with display names and team names, keyed by user_id. It also specifies the exact return format and explicitly distinguishes itself from rosters by noting this is the only place a human name lives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states this is the ONLY place a human name lives, contrasting with rosters that carry owner_id, not names. Also notes auth is none needed, so the agent knows it can be called without credentials.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sleeper_userA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it specifies the exact return fields ({user_id, username, display_name, avatar, is_bot}), states that no auth is needed, and clarifies the distinction between username and user_id input. It doesn't mention error cases or rate limits, but for a simple lookup tool this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: purpose, return values, example, and auth in four short lines. Every sentence earns its place, and the example is directly useful. No fluff or redundant details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity (1 parameter, no output schema), the description provides everything needed: input format, return fields, and downstream usage. It even tells the agent what to do with the result. Annotations cover the safety dimensions, so no additional behavioral details are necessary for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema description already explains that username_or_id is 'Sleeper username, or a numeric user_id... part of the URL path'. The description's example and mention of 'username (or user id)' add little beyond the schema. It does reinforce the dual nature of the parameter, but baseline 3 is appropriate since the schema carries the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action: 'Look up a Sleeper user by username (or user id)'. It also positions it as 'the first step to finding someone's leagues', which differentiates it from sibling tools like sleeper_user_leagues and sleeper_league. This is a specific verb+resource with a defined scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly guides when to use this tool: it's the first step to finding leagues, and it states that the returned user_id is what 'sleeper_user_leagues needs'. This provides clear contextual guidance and a next step, effectively telling the agent when and how to chain this tool with others.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• squiggle_ladderA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the tool as read-only, idempotent, and open-world, so no safety contradiction exists. The description adds valuable behavioral context beyond annotations: it explains that 'rank' is projected (not actual), describes the 'swarms' distribution, and notes the data size implication (~100 KB) and that no auth is needed. This enriches the agent's understanding without repeating annotation properties.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence purpose, a structured return format, an example query, and an auth note. Every sentence contributes unique information, and the return payload is clearly formatted with field names, making it scannable and free of filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description includes the full return structure, semantics of key fields, an example invocation, and authentication requirements. It also addresses the practical concern of data size and differentiates from a sibling tool, making the description self-sufficient for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides descriptions for all parameters (100% coverage), so the baseline is 3. The description goes further by advising 'q' is fixed ('Leave as-is') and recommending the 'round' parameter based on data size ('Recommended — a season is ~100 KB'), adding practical meaning that aids parameter selection.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'PROJECTED end-of-season ladder per model', clarifying this returns simulated projections, not actual standings. It explicitly distinguishes itself from squiggle_standings by stating 'rank here is PROJECTED, unlike squiggle_standings' and introduces the unique 'swarms' field, making the tool's purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: it is for projected ladders, directly contrasting with squiggle_standings. It also offers parameter guidance ('round: Projection as at this round. Recommended — a season is ~100 KB'), helping the agent decide on parameter values. However, it does not explicitly state when *not* to use it or name other alternatives beyond squiggle_standings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• supercoach_playerA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as readOnly, idempotent, and openWorld. The description adds value by disclosing the exact return shape and the fact that it is a subset, plus the useful note about no auth required. No contradictions, and it does not need to repeat safety traits already conveyed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: purpose, return shape, example, and auth note. Every sentence contributes and there is no repetition of schema fields. It is appropriately sized for a simple read operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-record fetch with four well-documented params and no output schema, the description provides the return shape, an example, a clear differentiation from the richer sibling, and auth expectations. This is complete for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all four parameters with complete descriptions (100% coverage), so the description does not need to add much. It provides an example that shows parameter values, but does not add semantic meaning beyond what the schema already offers.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves a single player's base record by SuperCoach id, enumerates the exact fields returned, and explicitly contrasts itself with the richer supercoach_players endpoint. This specific verb+resource+scope fully distinguishes it from sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives an explicit usage directive: use this for a thin base record, and use supercoach_players with a round for full price/projection/matchup data. It also provides a concrete example with sport 'afl', year 2026, and id 1, and notes auth is not needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_cms_callA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already assert readOnly, idempotent, and openWorld. The description adds genuine behavioral context: the specific endpoint, built-in query defaults (platform, os, jurisdiction, authentication-status), jurisdiction override capability, authentication behavior, and return type. This goes well beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-structured: a direct first sentence, a helpful query-defaults hint, and clear Returns/Auth callouts. No filler or irrelevant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With a single required param, annotations confirming read-only behavior, and no output schema, the description covers the key decision factors: endpoint, valid operations, dynamic query overrides, return shape, and authentication. The pointer to a catalogue resource fills the need for a complete operation list.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides all parameter definitions, so the baseline is already solid (100% coverage). The description adds value by explaining that query_params can override jurisdiction, listing the standard defaults, and pointing to the operations catalogue for valid operation values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches 'one of TAB's CMS content feeds' from cmsapi.tab.com.au and identifies the operation names (homepage / offers / promotions / racing). This distinguishes it from other tab_* and sportsbet_cms_* siblings and describes a specific verb plus resource.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use case is apparent: fetch CMS content by operation name, and the description guides the agent to 'Read tab://cms/operations for the list.' It does not explicitly state when not to use this tool or name alternatives, so it isn't a full when/when-not guide.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tab_sports_next_to_goA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds auth requirements ('works without a key; TAB_CLIENT_ID or TAB_CLIENT_SECRET unlocks more'), the return shape ('Returns: {matches:[...]}'), and the ordering behavior. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each adding a distinct piece of value: purpose, return format, and auth. No fluff, repetition, or extraneous details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the annotations (read-only, open-world, idempotent) and 100% schema coverage, the description covers the essential aspects of the tool: what it does, what it returns, and auth requirements. It is sufficient for an agent to invoke this read-only feed tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description covers 100% of parameters with individual descriptions, so the baseline is 3. The description does not add any parameter-specific semantics, but that is acceptable given the rich schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description says 'Sport events about to close, ordered by close time (next-to-go sports feed)', which is a specific verb and resource, clearly distinguishing it from racing-specific siblings like tab_racing_next_to_go or general sports listing tools like tab_sports.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'next-to-go sports feed' clearly indicates when to use this tool: when you need sport events about to close, ordered by close time. It does not explicitly name alternatives or when-not-to-use cases, but the context is unmistakable and sufficient for most agents.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_trendsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds valuable context beyond the annotations: expected return shape ('{data:[{trend_name, tweet_count}]}'), a concrete usage example, and the authentication requirement ('needs your own key in X_BEARER_TOKEN'). It does not contradict the readOnlyHint, openWorldHint, or idempotentHint annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tight and well-structured: one line for purpose, one for return format, one compact example, and one for auth. Every sentence earns its place with no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 explicitly listing the return shape. It covers purpose, parameter semantics via examples, and the critical authentication detail. The concise example makes the tool easy to invoke correctly, and the annotations already cover the safety profile.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents all three parameters with descriptions, so the baseline is 3. The description enhances this by providing real WOEID examples (1, 23424977, etc.) and a full example invocation, helping an agent understand what values are meaningful even though the schema also explains them.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb+resource: 'Trending topics for a location by WOEID', with concrete examples (1, US, Australia, UK). This distinguishes it from sibling Twitter tools like twitter_search_recent or twitter_tweet_counts, which focus on search or counts rather than trends.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Gives clear context for use (location-based trending topics), provides a minimally working example, and lists common WOEIDs. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to know when to invoke it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ufc_athleteA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnly/idempotent annotations already present, the description adds substantial behavioral context: statistics are in `included` rather than on the athlete, heights/weights/reaches are inches/pounds as decimal strings, and no auth is needed. The example response makes the return shape concrete, and nothing contradicts the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, then uses a structured return example, unit clarification, auth note, and a reference to a sibling tool. Every sentence earns its place, and the JSON example improves clarity without excessive verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema is provided, but the description compensates by detailing the full response shape, where statistics and rankings live, the units, and an example. It also covers auth and points to ufc_athlete_stats for the full field list, making invocation unambiguous.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage for parameters is 100%, so the baseline is 3. The description's example duplicates the schema's `title` example and does not introduce additional parameter semantics beyond what the schema already documents, such as the `include` warning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The first sentence clearly specifies the tool returns one fighter with full career statistics and current ranking attached. Calling it "The main athlete tool" and explicitly noting that statistics live in `included` distinguishes it from sibling tools like ufc_athlete_stats and ufc_rankings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description instructs that `title` must be an exact fighter name "from ufc_search_athletes", establishing a clear prerequisite and workflow. It also references ufc_athlete_stats for the full field list, providing an alternative, though it does not explicitly state exclusions or when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ufc_athlete_statsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds crucial behavioral facts: the filter parameter returns 0 rows instead of an error (verified), sorting is confirmed to work, and data quirks are documented (e.g., the `takedown_acuracy` misspelling, percentages/rates as strings, `avg_fight_time` in seconds, and per-15-minute averaging convention). This goes far beyond the annotations and prevents misuse.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy but well-structured into distinct segments: purpose/alternative, return payload, caveats, example, and auth. The inline return schema is dense but necessary since there is no output schema. Each sentence serves a purpose, and key warnings are front-loaded. It is not as short as the ideal TDQS 4.3 example, but the density is justified by the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity and the absence of an output schema, the description is remarkably complete. It specifies the full return structure with all attribute names, explains non-obvious unit conversions and string formatting, documents the filter failure mode, names the working alternative, and provides an example call. The auth requirement is also stated. This is more than sufficient for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter has a description, so the baseline is 3. The description adds value beyond the schema by providing a concrete example (`{"sort": "-sig_strikes_landed", "limit": 10}`), listing verified sort fields, and explaining that `sort` is how you build a leaderboard. This practical invocation guidance helps the agent select and construct parameters correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with "League-wide FightMetric statistics, sortable — the all-time leaderboards," which clearly identifies the resource as league-wide all-time stats. It lacks an explicit retrieval verb like "list" or "get," but the Returns block and the guidance to use ufc_athlete for a single fighter make the tool's purpose unambiguous. It also distinguishes from the sibling ufc_athlete by scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when not to use this tool: "this collection cannot be filtered" and directs users to ufc_athlete for single-fighter stats, even noting that ufc_athlete resolves the same record through `include` and "DOES work." It also clarifies that sorting works, which is the intended leaderboard use case, and provides a concrete example.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ufc_jsonapi_indexA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only/idempotent behavior, and the description adds valuable context: the exact return structure (map of resource types to collection URLs), the count of 291 entries, the fact that auth is not needed, and a heuristic that most entries are non-sport CMS data. This goes meaningfully 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but not bloated: purpose, return structure, use case, auth, and a caveat are all covered in four concise lines plus a compact example. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no parameters and no output schema, the description fully covers what the tool returns, the structure of the response, when to use it, and authentication. It even warns about the mix of CMS plumbing vs. sport data. No notable gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 focuses on the response shape instead of parameters, which is appropriate since there is nothing to explain about inputs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as the JSON:API resource index for all 291 resource types ufc.com exposes, with the specific purpose of discovering surfaces not wrapped by the spec. It distinguishes itself from sibling UFC tools (events, athletes, rankings) by being the comprehensive index.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states when to use it: 'useful when you need something this provider does not expose,' and warns that most resources are CMS plumbing rather than sport data. It could name alternative UFC tools, but the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wta_tournamentA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which cover safety and idempotency. The description adds that no auth is needed ('Auth: none needed') and explicitly lists the return structure, providing useful behavioral context beyond the annotations. It doesn't discuss error handling, but that's not a major gap given 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a concise definition, a clear 'Returns' block, a practical example, and an auth note. It avoids repeating schema content and every sentence adds value. It's front-loaded with the core purpose, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only lookup, the description covers all essential aspects: request construction (including ID source and URL pattern), response fields, and authentication requirements. With no output schema, the explicit field list compensates adequately. The example further grounds the usage. This is complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of parameters with clear explanations. The description goes further by linking groupId to a real example (901 = Australian Open), showing the combined #/901/2025# path, and specifying that IDs originate from wta_tournaments. This adds meaningful usage context on top of the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: returns one tournament edition identified by tournamentGroup id and year. It distinguishes itself from sibling tools like wta_tournaments by focusing on a single edition, and it provides a concrete example (groupId 901, year 2025) that leaves no ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear contextual guidance: IDs come from wta_tournaments, implying a two-step flow. It also explains the URL path pattern. However, it doesn't explicitly state when to use this tool over related siblings like wta_tournament_matches, but the context is sufficient for an agent to infer the right scenario.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_football_fixturesA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly/openWorld/idempotent. The description adds important context: authentication requirement ('needs your own key in API_SPORTS_KEY'), the unverified nature of the payload shape, and the domain nuance that `goals` is the 90-minute score while `score.penalty` decides shootouts. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and information-dense: purpose, return shape, caveat, example, and auth note. Each section earns its place, and the caveat about unverified vendor docs is crucial transparency.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 compensates with a detailed return shape and key semantics (penalty vs goals). It also explains the approximate nature of the shape. However, it does not mention combination rules (e.g., season required with league/team) or pagination, though the schema covers the season requirement.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers all 9 parameters with descriptions (100% coverage), so baseline is 3. The description adds value by requiring 'at least one filter' (since all params are optional in schema) and provides a concrete example using the `date` parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Football fixtures and results by date, league or team', providing a specific resource and scope. It differentiates from sibling tools like apisports_football_leagues and apisports_football_standings by focusing on fixtures/results.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs 'Give at least one filter', which is a key usage constraint. The example shows a valid date filter call. It does not explicitly compare with alternatives, but the filter guidance is clear and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apisports_statusA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as readOnly, openWorld, and idempotent. The description adds valuable context beyond that: it costs no quota, the response shape is from vendor docs and unverified, and it warns to inspect the actual payload. It also discloses auth requirements (API_SPORTS_KEY). This is meaningful supplemental information.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections: purpose, return shape, caveat, example, and auth. It is longer than strictly necessary, but every part adds value—especially the reliability warning about the unverified shape. It is front-loaded with the core purpose and usage guidance, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 detailing the return shape, including nested fields, and noting it's approximate. It also covers auth, quota cost, and when to use it. This is a complete picture for a no-parameter tool, enabling correct selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so schema coverage is complete by default. The description doesn't need to explain parameter semantics, and it doesn't; it appropriately focuses on the response and usage. The baseline of 4 for zero parameters applies here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool returns subscription details and remaining daily quota, which is a distinct purpose from the many data-fetching siblings. It identifies the resource (API Sports account status) and the intent is unmistakable, even without an explicit verb like 'get' or 'check'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit guidance: 'Costs no quota — call it first when something returns empty.' This tells the agent exactly when to invoke this tool, and the 'Example: Quota check' reinforces the diagnostic use case. While it doesn't name alternatives, none are relevant for a quota check.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_pending_transactionsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/idempotent annotations, the description discloses key behavioral details: the return key is ABSENT (not empty) when no pending transactions exist, and cookie-based auth unlocks more data. These are not visible in annotations and provide valuable operational context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized into purpose, return shape, example, and auth. Every sentence conveys a distinct piece of information with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description explains the top-level return shape (pendingTransactions array and its absence behavior). However, it does not describe the structure of individual pending transaction items, leaving a gap for agents needing item-level details. Still, for a list-type read tool with good annotations, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 a concrete example call with realistic values for game, seasonId, leagueId, and scoringPeriodId, demonstrating parameter usage beyond the schema's basic definitions. This example aids an agent in constructing a valid request.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly identifies the resource as 'Pending/unprocessed transactions' and further specifies 'waiver claims and trade offers awaiting processing.' It distinguishes from sibling espnfantasy_transactions by the 'pending/unprocessed' qualifier, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description includes a use-case example ('Outstanding waiver claims / trade offers') and mentions auth prerequisites ('needs the private cookie in most leagues') and behavior without a key. It does not explicitly name alternates like espnfantasy_transactions, but the contrast is implied by 'pending/unprocessed.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• footballdataorg_matchesA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that the envelope is verified live and works without a key (though keyless calls see no competitions), and explicitly warns that the match object shape is unverified and approximate. It also flags the score location in score.fullTime. These enrich the readOnly/openWorld/idempotent annotations with genuine behavioral details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average but earns its length: a purpose sentence, detailed return shape, an unverified-shape caveat, an example, and auth instructions. It is front-loaded with the core purpose and organized with clear sections.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description supplies a full return envelope and match object shape, plus a caveat about reliability. It covers auth, keyless behavior, and date constraints, making it sufficient to invoke correctly for a read-only list operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes all four parameters (dateFrom, dateTo, status, competitions), but the description's opening sentence clarifies that omitting competitions returns matches across every visible competition – a default behavior not in the schema. The example illustrates a minimal date-range call, adding practical usage beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Matches across every competition your key can see, for a date range' – a specific resource (matches) with clear scope (all visible competitions, date range). It distinguishes from siblings like footballdataorg_competition_matches (competition-specific) and footballdataorg_match (single match).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'every competition your key can see' indicates this is the cross-competition, date-range tool, contrasting with competition-specific endpoints. No explicit alternative is named, but the scope is clear. The example and auth note provide context for when a key is needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• footballdatauk_seasonA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnly, openWorld, idempotent), the description discloses that ALL VALUES ARE STRINGS, dates are DD/MM/YYYY, and the C suffix in odds columns indicates closing odds. It also specifies auth is not needed and provides a sample output structure, which are valuable details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a one-sentence summary, a sample return, explicit notes on types/date/odds, an example, and auth. Every sentence contributes practical information without padding, and the essential detail is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description enumerates most columns and explains the key formatting pitfalls (strings, date format, closing odds naming). The sample return with '…' suggests some columns are omitted, but the core data shape is clear. Auth and example are included, making it quite complete for a simple season-retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers 100% parameter descriptions, including season format and division codes. The description adds a concrete example with 'season': '2425' and 'division': 'E0', and references the division list in the schema. This slightly augments the schema, so a strong baseline score is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns one league season with every match, scores, shots, cards, and closing odds from ~10 bookmakers. It explicitly calls it 'The backtesting dataset', distinguishing it from other football data tools like footballdataorg_* or pl_*. The included example and field list reinforce the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides strong context by labeling this as 'The backtesting dataset' and emphasizing closing odds, implying it is for backtesting scenarios. It gives an example invocation, but does not explicitly name alternative tools or state when not to use it. Schema documents division codes, so context is clear but exclusions are absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_set_piece_notesA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the read-only and idempotent annotations, the description discloses the return structure, auth behavior (works without a key, FPL_SESSION_COOKIE unlocks more), and the nature of the data (official notes, subject to injuries). This adds substantial context not encoded in 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with purpose, return format, use case, example, and auth info clearly delineated. It's slightly promotional in the 'genuinely useful' section and the 'Example' line is a bit informal, but overall each part adds value and it remains reasonably concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no parameters and no output schema, the description is remarkably complete. It covers what the tool does, the shape of the returned data, an example note, the auth requirement, and practical use cases, giving an agent all necessary information to select and call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so schema coverage is complete and a baseline of 4 is appropriate. The description enriches the tool's semantics by showing an example of the data content (e.g., 'Penalties: Haaland, then Alvarez'), though it doesn't need to explain parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides official set-piece taker notes per club, specifying who takes penalties, corners, and free kicks. This is a specific, distinguishable purpose among the many FPL sibling tools, and the 'Example: Who takes the penalties' reinforces the use case.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description notes the tool is 'genuinely useful for FPL and priced-market work alike' and adds context about penalty duty being valuable and subject to injuries. However, it doesn't explicitly mention when to avoid it or name alternative tools, so it lacks exclusionary guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• motogp_seasonsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the read-only/idempotent annotations, it discloses the exact return shape (array of {id, year, current}), ordering (newest first), semantics of the 'current' flag, and that no auth is required.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with purpose, followed by return structure and auth. The 'Example: All seasons' line is somewhat redundant but does not add meaningful length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter read-only listing tool, this description fully equips an agent: it explains the output format, the meaning of each field, ordering, and lack of auth. No gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool takes zero parameters, and the empty schema is fully described. The description adds no parameter-specific details, but none are needed; baseline 4 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  'Every MotoGP season (1949 →) with its uuid' clearly states the resource and scope, and 'the entry point to everything else' distinguishes it from sibling tools like motogp_events and motogp_standings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'the entry point to everything else' and that 'id' is the seasonUuid other tools need, giving clear when-to-use context. It does not name specific alternative tools, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_match_outcomesA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds meaningful context beyond these: the response structure ('type, count, data'), the per-team grouping of outcome rows, and the absence of auth requirements. It also specifies the season-start-year convention via parameter documentation. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the core purpose, and every sentence adds value: the first sentence states what it does, the second describes the return shape, and the third clarifies auth requirements. No filler or repetition of schema details beyond helpful context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has a simple 2-parameter schema, clear annotations, and no output schema, the description is largely complete: it covers the resource, the grouping, the response envelope, and auth. It doesn't detail exact row fields (e.g., home/away scores), but the description says 'per-match outcome rows' and the schema handles the input side. Slightly more detail on what fields are in each row would push it to 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already has 100% coverage, so the baseline is 3. The description adds value by explaining the year parameter's season-start semantics ('2025 = NBL26') and why it is required ('part of the URL path'). It also gives context for the seasonType parameter by showing example enum values inline (regular, finals, preseason), reinforcing the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with 'Per-team match outcomes (results) for a season — win/loss rows by team, for head-to-head and form analysis.' This clearly identifies the resource (match outcomes), the grouping (per-team), and the intended analytic use cases (head-to-head and form analysis). It distinguishes itself from siblings like nbl_ladder (standings), nbl_schedule, and nbl_next_matches by focusing on historical win/loss rows per team.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains the purpose of the data ('for head-to-head and form analysis'), which strongly implies when to use it. It also includes a return shape and notes that no auth is needed. However, it does not explicitly name alternative tools or state when not to use it, so it falls just short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• oddsapiio_eventsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the read-only/idempotent annotations by disclosing authentication requirements (own key in ODDS_API_IO_KEY) and, most importantly, explicitly stating the return shape is from vendor docs and NOT verified against a live response. This caveat tells the agent to inspect actual payloads before relying on field names, a high-value behavioral warning.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured into labeled sections: summary, return shape, caveat, example, and auth. It is slightly longer than strictly necessary but every sentence earns its place. The caveat and example are valuable, and the formatting aids readability.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description compensates by listing the return fields and warning that the shape is approximate. It also covers authentication, parameter usage via example, and clarifies the tool's scope (no prices). For a simple read-only list tool, this is a complete and self-sufficient description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 a concrete usage example ({"sport": "football"}) that illustrates how to pass the sport parameter. This extra example helps clarify the intended call structure, improving over mere schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Upcoming events for a sport or league, without prices.' This is a specific verb (retrieve/list) plus a concrete resource (events) and a distinguishing scope (sport/league, no prices). It also provides the return shape and an example, making the purpose unmistakable and differentiating it from odds-related siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool (upcoming events without prices), implies exclusion (don't use if you need prices), and includes an example query. However, it never explicitly names an alternative tool like oddsapiio_odds, relying on implicit inference rather than direct guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• oddsapiio_sportsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond annotations by disclosing that no API key is required, that the tool is verified live, and that the response shape is unverified and approximate per vendor documentation. This is valuable transparency about reliability and return format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is mostly front-loaded with the key point, but includes some redundancy: 'VERIFIED live — works without a key' appears twice, and the caveat note is a bit verbose. Still, it's compact enough.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only tool, the description covers purpose, return shape with an example, authentication requirement, and a reliability caveat. It's fully self-contained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema is empty; the description correctly doesn't address parameters. There is nothing to add because no parameters exist, so this is a non-issue.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists the 34 sports with their slugs, and explicitly notes that every other tool needs these slugs, distinguishing it from sibling tools. The return example makes the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states the tool works without a key, implying it can be used as a prerequisite for other OddsAPI tools that need slugs. It doesn't name specific alternatives but gives clear context on when to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pandascore_videogamesA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context by disclosing the auth requirement (PANDASCORE_TOKEN) and the unverified status of the response shape ('NOT been verified against a live response'), advising the agent to inspect actual payload. No contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with clear sections (purpose, usage, return shape, caveat, auth). It is front-loaded with the key purpose. The 'Example: All titles' line is somewhat redundant and the note is slightly verbose, but each part adds some value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 0-param read-only tool, the description covers purpose, usage timing, return shape (top-level array with specific fields), auth, and data reliability caveats. Since there is no output schema, the return shape example and the warning about unverified data are critical and well provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema offers no information. The baseline for 0 params is 4. The description compensates by providing the return shape example, which helps the agent understand what to expect even though parameters are absent.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'The titles PandaScore covers, with the slug every other tool needs' – a specific verb+resource with explicit scope. It distinguishes from sibling tools by focusing on videogame titles and their slugs, positioning itself as a prerequisite for other PandaScore tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly instructs 'Call this first rather than guessing a slug', which directly tells the agent when to use this tool and why. This establishes a clear usage order relative to other tools that depend on slugs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• seriea_playersA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral details: category values other than General/Goalkeeping return 400, pageSize parameter is ignored, pagination fields (totalPages/isLastPage), and the return structure. It also confirms no auth is needed, exceeding what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with distinct sections: purpose, pagination, category warning, return format, example, and auth. It is somewhat long but every sentence adds valuable information without redundancy. The use of code blocks and notes improves readability.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description compensates by fully specifying the return shape. It also covers critical constraints (category values, pagination, auth), provides an example, and addresses potential misuse. This makes it comprehensively actionable for an AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema: category selects the stat set rather than filtering by position, and the example provides a concrete seasonId and page usage. It also clarifies pagination fields, which the schema only partially communicates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns every player in a season with identity and full Opta stats, which is a specific verb+resource pair. It distinguishes itself from sibling tools by noting 'no separate squad call needed' and clarifying the scope (all players, not just a squad).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides strong usage context: pagination behavior (30/page, pageSize ignored), category semantics (not a position filter), and an explicit example. It implies alternatives ('no separate squad call needed') but does not name specific sibling tools, slightly reducing its guidance value.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportmonks_fixtures_by_dateA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent hints, but the description adds substantial context: the exact response shape, the behavior of the `include` parameter (without it, no teams/scores), the structure of `scores` (list of period scores requiring selection of CURRENT), the authentication requirement, and a clear warning that the shape is unverified from vendor docs. This goes well beyond the structured hints and provides critical operational context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than the ideal one-liner but every sentence serves a purpose: purpose, include warning, response shape, caveat, example, and auth. It is front-loaded with the core purpose and structured with line breaks for readability. The caveat and shape details add necessary length for a tool with no output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 it does so thoroughly, including the exact data structure, how to interpret `scores`, the unverified-shape warning, an example call, and auth requirements. The pagination field is mentioned, and the tool's simplicity (one date, three params) means this is comprehensive for an agent to use correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for all three parameters, so the baseline is 3. The description adds value by warning that omitting `include` results in IDs only, and by explaining the nested `scores` structure and how to extract the live/final score. It reinforces the meaning of `include` and `date` with a concrete example. The `per_page` parameter is not further elaborated, but the schema already describes it as 'Page size.'

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Fixtures on one date,' which clearly states the tool's function: retrieving sports fixtures for a single date. It distinguishes itself from sibling tools like sportmonks_fixture (likely a single fixture) and sportmonks_livescores by specifying the date-scoped query. The additional note about the `include` parameter clarifies what the tool returns by default.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage instructions: it tells the user to add `include=participants;scores` to avoid getting bare IDs, and includes a concrete example. However, it does not explicitly mention when to prefer this tool over alternatives like `sportmonks_fixture` or `sportmonks_livescores`, so it lacks explicit exclusionary guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• theoddsapi_eventsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, idempotent hints, but the description adds valuable behavioral context: the response shape includes no bookmakers, the shape is unverified from vendor docs and should be inspected, auth via THE_ODDS_API_KEY is required, and the call costs no quota. These go beyond the structured annotations and inform the agent of important caveats.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with labeled sections: purpose, return shape, caveat note, example, and auth. Each sentence earns its place. It is slightly longer due to the unverified-shape warning, but that is necessary context. No redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list endpoint with 2 params and no output schema, the description is complete. It covers purpose, return shape, example usage, auth requirement, and a critical caveat about unverified data. The annotations handle safety and idempotency, so nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema covers both parameters with descriptions (100% coverage), so the baseline is 3. The description adds an example ('{"sport": "soccer_epl"}') and repeats that sport is a sport_key, but does not add new semantics beyond the schema. It doesn't describe valid sport_key values or further explain dateFormat.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States clearly: 'Upcoming events for a competition WITHOUT odds.' This gives a specific verb+resource+scope and differentiates from sibling odds tools (e.g., theoddsapi_odds) by explicitly excluding odds. The example 'Upcoming EPL fixtures' further clarifies the intended use.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance: 'Free — costs no quota — so use it to find event ids cheaply.' This explains the primary use case and implies when-not-to-use (when odds are needed, since it says WITHOUT odds). It lacks a named alternative but gives clear context and a specific motivation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ufc_event_cardA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish read-only, open-world, idempotent behavior. The description adds valuable context beyond that: the response shape, that the fight card is in `included` and matched via `data[0].relationships.fights.data[].id`, and that 'nothing useful is inline'. It also notes no auth is needed. This goes beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than necessary due to the detailed return structure example, but every piece is informative and logically organized: purpose, usage, return format, example, auth. There is minor redundancy with the schema (e.g., include description repeated), but overall it is well-structured and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description provides a detailed breakdown of the return payload, including the critical note that fights live in `included`. It covers parameters, example, and auth, making it complete for an agent to invoke and interpret the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds value with a concrete example ({"title": "UFC 330"}) and clarifies the include parameter's default behavior ('Leave as-is to get the bouts with both fighters resolved'), which reinforces the schema description but adds practical usage context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'One event WITH its full fight card attached' which clearly defines the scope, and it explicitly differentiates from sibling tool ufc_events by saying 'Use this rather than ufc_events when you want the bouts.' This is a specific, resource-focused purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Directly names the alternative tool (ufc_events) and the condition for choosing this one ('when you want the bouts'). Also provides an example invocation with title, clarifying the main intended use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ufc_round_recordsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds substantial behavioral context: the return shape with `combined` flag semantics, the warning that `filter[round]` and `filter[statname]` return 0 rows instead of errors, the fact that `value` is a string, and that no auth is needed. This goes far 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is reasonably concise for the amount of information it conveys. It is well-structured with Returns, Warning, Example, and Auth sections. The warning and example are directly useful. A slight deduction for some verbosity, but every section earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 fully explaining the return structure, the meaning of `combined`, the statname enumeration, round range, and the filter limitation. It includes an example and auth info, making it complete for an agent to use correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for sort, limit, and offset, giving a baseline of 3. The description adds meaningful semantics by warning that filtering params don't work server-side, advising to request a full page and narrow manually, and explaining that sorting works. This adds value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as 'The single-round record book' with specific stats (significant strikes, total strikes, takedowns, submission attempts) and explicitly says it is ranked. This is a specific verb+resource that distinguishes it from sibling tools like ufc_fights or ufc_athlete_stats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use the tool (to retrieve single-round records) and gives practical guidance on filtering, combined totals, and resolving IDs via ufc_search_athletes. It doesn't explicitly exclude alternative tools, but the purpose is distinct enough that the usage context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_player_statsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, openWorld, and idempotent. The description goes well beyond that by providing an approximate return shape, a rate-limiting batching hint, auth requirements, and a caveat that the shape is unverified—valuable context for an agent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a summary, return shape, example, and auth note. It's detailed but each part contributes useful information. It could be slightly trimmed (the return shape is verbose), but overall it's efficient and clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even without an output schema, the description provides an approximate response shape, a usage example, auth requirements, and batching advice. It addresses all key aspects an agent needs to invoke the tool correctly, making it highly complete for its complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 a concrete example of playerKeys and type, and emphasizes batching, which helps an agent format the request correctly. This is a modest but useful improvement over the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns stats for one or more players for a season or week, which is specific and distinguishes it from team/league-level tools. The example and batching note reinforce its exact purpose, making it unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool (player stats) and includes a batching tip for rate limits. However, it doesn't explicitly mention alternatives or when not to use it, so it falls just short of full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_team_rosterA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds valuable behavioral context. It warns that the return shape is from vendor docs and unverified, discloses auth requirements (YAHOO_CLIENT_ID, etc.), and explains that is_editable false leads to write failures for future writes. This transparency about limitations and semantics goes well beyond the structured fields, aiding the agent in setting expectations correctly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-structured with clear labels ('Returns:', 'NOTE:', 'Example:', 'Auth:'). Each section serves a distinct purpose: core definition, return shape, caveat about unverified data, illustrative example, and authentication notes. While lengthy, the organization prevents it from feeling wasteful, and the front-loaded first sentence immediately conveys the tool's purpose. A slight deduction for the verbosity of the return shape, which could overwhelm some agents.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description takes full responsibility for explaining the return shape, providing a detailed breakdown of the response structure. It covers auth, usage example, and a critical caveat about the unverified shape. This is a complex API (Yahoo fantasy), and the description thoroughly equips the agent to parse and use the response, including edge cases like is_editable locks.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema coverage, the baseline is a 3. The description adds value through a concrete example ({"teamKey": "449.l.12345.t.3", "week": 1}) and clarifies the meaning of 'week' in the context of lineup changes ('the current week is what a lineup write changes'). This goes beyond the schema's minimal field descriptions, though that added insight is modest given the schema already covers the essentials.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb and resource: 'A team's roster for a week — who is started, benched, and in which slot.' It distinguishes itself from siblings like yahoo_team and yahoo_team_stats by focusing on lineup/bench/slot details, and the phrase 'read that precedes every lineup write' further clarifies its niche. This is unambiguous and specific, going beyond a generic restatement of the name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: 'The read that precedes every lineup write' and explains that is_editable false means the week is locked, implying when the tool is relevant. However, it does not explicitly name alternatives or state 'use this instead of X' for edge cases like team info or stats. Since the sibling list includes similar Yahoo tools, the lack of explicit alternatives keeps it slightly short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entain_graphql_callA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description provides rich behavioral details beyond the annotations: it discloses the self-healing APQ-cache mechanism (re-POSTing the stored query document), the fallback command (`sportsdata-mcp refresh-hashes entain`), exact ID format expectations for GraphQL variables (type-prefixed vs bare UUID), and that no authentication is required. These details are not available in the annotations (readOnlyHint, openWorldHint, idempotentHint) and greatly help an agent invoke the tool correctly. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but exceptionally well-structured. It front-loads the core purpose in the first sentence, then adds crucial operational details in a logical order, and ends with labeled sections ('Returns:', 'Auth:') for quick scanning. Every sentence adds necessary information—no filler or repetition of schema fields. It's long due to the inherent complexity of the 127-operation GraphQL gateway, but remains efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's inherent complexity (127 operations, no output schema), the description is remarkably complete. It explains how to discover valid operations and variable signatures (catalogue resource), how to handle a specific error state, and what ID format to use. The 'Returns: JSON object' line is minimal, but since the return shape varies per operation, a generic statement is appropriate. The description fully equips an agent to use the tool correctly, covering auth and error recovery.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers both parameters with clear descriptions (100% coverage), so a baseline 3 applies. The description adds valuable semantics beyond the schema: it explains that operation names come from the catalogue resource and that guessing returns an error listing alternatives, and it details the GraphQL ID prefix rules for variables ('ID! wants the prefixed form, UUID! wants the bare uuid'). These are non-obvious and critical for correct parameter values, pushing the score to 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb ('Call') and precise scope: 'any of Entain's 127 persisted GraphQL operations against api.ladbrokes.com.au/gql/router by name + variables.' This clearly distinguishes it from sibling tools like sportsbet_graphql_call (different provider) and Entain-specific typed tools like entain_racing_racecard. The mention of 'persisted operations' and the endpoint unambiguously identifies the tool's function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a clear general usage context: use this tool when you need to execute an Entain persisted GraphQL operation by name and variables. It points to the catalogue resource ('Read entain://graphql/operations') for the full operation list and signatures, providing a helpful 'next step' for the agent. However, it does not explicitly state when not to use this tool versus more specialized Entain tools (e.g., entain_racing_racecard), which would push to a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• entitysport_match_commentaryA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/idempotent hints, the description discloses critical behavioral aspects: the response shape is unverified from vendor docs, includes non-ball events that need filtering, and requires a personal API key (ENTITYSPORT_TOKEN). These add substantial transparency about what the agent will receive and what prerequisites exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Each section earns its place: one-line summary, return shape, filtering caveat, verification alert, usage example, and auth requirement. Formatting with bolded notes and an indented example improves scannability without padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description compensates by providing a detailed return-shape sketch, an explicit warning about unverified fields, a filtering note, a JSON example, and auth guidance. This gives an agent nearly everything needed to invoke the tool and interpret its response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already fully documents both parameters (matchId, inningsId) and even clarifies inningsId as 'iid from the scorecard.' The description adds an explicit usage example and clarifies the context (an innings's commentary), reinforcing the meaning but not adding substantial new semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Ball-by-ball commentary for an innings' — a specific verb and resource. It also explicitly differentiates from a sibling: 'the reason to choose this provider over cricketdata.' This uniquely identifies the tool among the many data-provider tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides strong usage context by naming cricketdata as an alternative and explaining why to choose this provider. It also gives operational guidance ('filter on `event` before counting deliveries'). However, it stops short of enumerating explicit when-not-to-use scenarios or other alternative providers (e.g., entitysport_match_scorecard).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_boxscoreA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds significant behavioral context beyond the annotations: it explains auth requirements ('works without a key; ESPN_FANTASY_COOKIE unlocks more'), provides the full return structure (important since there is no output schema), and warns that omitting scoringPeriodId yields season totals. This goes well beyond the readOnlyHint annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded: a clear purpose sentence, followed by a compact return type, an example, and an auth note. Every section earns its place, with no redundancy. The return type is dense but necessary given the lack of an output schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema and moderately complex parameters, the description covers all essential gaps: return shape, example invocation, auth behavior, and the critical requirement for scoringPeriodId. Annotations handle safety and idempotency, and the schema covers parameter details. The description is complete enough for an agent to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 a concrete example showing how the parameters map together (game, seasonId, leagueId, scoringPeriodId) and implicitly uses the default view. While it doesn't add new semantic explanations beyond the schema, the example helps agents understand typical usage and parameter relationships, justifying a score above baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies what the tool does: 'Week box scores — each matchup with both lineups, per-player actual and projected points.' It also distinguishes from similar tools by calling it 'the start/sit post-mortem view,' which implies post-week analysis, differentiating it from live scoring or matchup summary tools. The return structure further clarifies the scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool: 'Week box scores' and 'post-mortem' indicate it is for after-the-fact review, and an example for Week 3 is provided. However, it does not explicitly mention when not to use it or name alternative tools (like live_scoring or matchup_score), so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_gamesA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds auth behavior (works without key, cookie unlocks more) and details the exact return structure, which is valuable context. It doesn't mention error cases or rate limits, but for a simple read-only discovery endpoint, this is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact yet fully informative: a one-line purpose, a mock return shape, a concrete example, and an auth note. Every sentence serves a purpose, and it is front-loaded with the core directive.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema and no parameters, the description fully explains what the tool returns and how to use it. The mock return object covers field names and nesting, the example clarifies usage, and auth is addressed. This is complete for a discovery endpoint of this simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so the input schema covers 100% by default. The description compensates by explaining the output structure (top-level array of 5 with currentSeason/currentScoringPeriod), which is essential for using the returned values. It provides a mock return object and clarifies how to resolve IDs, adding meaning beyond an empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists all five ESPN fantasy games with their current season IDs and scoring periods, with the specific directive to call it first to resolve seasonId/scoringPeriodId. This verb+resource structure (list/resolve) distinguishes it from sibling tools like espnfantasy_season, which appears to handle individual seasons.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states 'call this first to resolve seasonId/scoringPeriodId', providing a clear when-to-use directive. The example (resolve current NFL fantasy season + week) illustrates a concrete use case. It also notes auth requirements, indirectly guiding when a cookie is needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_classic_leagueA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint and idempotentHint, so the description builds on this by disclosing pagination behavior (50 per page), the meaning of 'entry' vs manager id, rank movement semantics, and auth requirements. These are valuable behavioral details beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the purpose, followed by a compact return shape, field clarifications, a concise example, and an auth note. Every sentence earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex paginated list with no output schema, the description fully specifies the return object, field semantics, pagination, example, and authentication. This is sufficient for an agent to select and invoke the tool correctly, especially given the sibling tool context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with good parameter descriptions, and the description adds semantic value by explaining leagueId 314 as the global league, how to find mini-league ids, and clarifying page size. This goes beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Classic (total-points) league standings, paginated,' which precisely names the resource and distinguishes it from H2H leagues. The return structure and example further reinforce the tool's specific function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'Classic (total-points)' qualifier clearly indicates when to use this tool versus the H2H sibling, and the pagination note gives practical context. It does not explicitly name alternative tools, but the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• laliga_teamsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnly, openWorld, and idempotent hints, so the bar for additional disclosure is met substantially. The description adds pagination behavior, approximate result count (~1541), return structure, the possibility of missing opta_id, join guidance, and auth requirements (works without key, subscription key unlocks more). This goes well 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, followed by critical usage caveats, return structure, example, and auth. Every sentence adds value and no extraneous content. Formatting with line breaks improves readability without bloating length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, so the description compensates by specifying the exact return shape: {total, teams:[{id, slug, name, nickname, shortname, boundname, shield, competitions}]}. It also notes the optional opta_id and pagination, covering all relevant aspects for a directory-like list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so both parameters (limit, offset) are already described as 'Page size' and 'Pagination offset (total ~1541)'. The description reinforces this with an example but does not add new semantic meaning beyond the schema's own descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool is a 'Global team directory across all competitions (~1541), paginated' specifically for resolving a team's slug/id/opta_id. It explicitly distinguishes itself from season-scoped tools like laliga_standing and laliga_subscription, making its purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit when-to-use guidance: 'use it to resolve a team's slug/id/opta_id' and what not to use it for: 'NOT season-scoped; for the 20 teams in a season read laliga_standing or laliga_subscription'. This directly names alternatives and gives clear exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nbl_next_matchesA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context beyond these: it discloses the return shape ({type, count, data:[...]}), notes the tool only returns upcoming matches (not completed), flags the empty off-season behavior, and states that no auth is needed. This goes well beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: it leads with the primary purpose, immediately provides the alternative tool for related cases, then lists the return format and auth requirement. Every sentence provides useful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is complete for a simple read-only tool: it explains the scope (upcoming matches per season), gives return structure, warns about off-season emptiness, names the sibling tool for full fixtures, and confirms no auth is needed. The schema fully documents the sole parameter, so no gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description covers the only parameter 'year' with detailed semantics (season start year mapping to NBL seasons and required URL path component). The tool description adds no additional parameter information. With 100% schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: returns 'Upcoming matches across all NBL teams for a season.' It also distinguishes itself from the sibling tool nbl_schedule by explicitly noting that the full fixture including completed games is available via nbl_schedule, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance on when to use this tool versus the alternative: use nbl_schedule for the full fixture including completed games. It also notes that the result may be 'empty in the deep off-season,' giving context about expected data availability.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pl_player_leaderboardA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (read-only, open world, idempotent), the description adds useful behavioral context by stating 'Auth: none needed' and detailing the exact return shape with pagination and data rows. This goes beyond the annotation hints and helps the agent understand the tool's side-effect-free and response behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence purpose summary, a clear return-type block, and a JSON example with an auth note. Every part earns its place without fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 specifies the return format, including the structure of playerMetadata and stats, and provides an example for clarity. It covers pagination, auth, and the key parameters, making it complete for a read-only leaderboard tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers all six parameters with descriptions (100% coverage), so the baseline is 3. The description enhances this by listing additional Opta metric examples (total_passes) and providing a full example request that demonstrates how cid, sid, sort, and limit are combined, adding meaningful value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it is a 'Player stat leaderboard for a season' with sorting by Opta metrics and filtering by position, which distinguishes it from team-level leaderboards and other player stat tools. The example of '2025/26 top scorers' reinforces the specific purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool (season leaderboard, sortable metrics, position filter) and provides a concrete usage example. However, it does not explicitly reference alternative player-stat tools or state when not to use it, so it falls short of full exclusionary guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• polymarket_sportsA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral details: returns a top-level array, no auth required, and lists output fields. While it doesn't discuss pagination or the meaning of 'resolution', it goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three compact sentences: purpose, return format, and auth. Information is front-loaded with the core purpose first, followed by essential details. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter catalogue tool, the description covers purpose, output structure, auth, and downstream usage. It is complete enough for an agent to select and invoke it correctly without further context, even without an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so the input schema is trivially complete (100% coverage) and the description cannot add parameter-level detail. The description compensates by explaining the returned fields, which helps an agent understand what to expect. This aligns with the baseline of 4 for 0-param tools.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this is a sports metadata catalogue providing tag ids, league/resolution links, and series, positioning it as the entry point for sports markets. It explicitly names the downstream tools (polymarket_markets/polymarket_events) and differentiates its role from those siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives concrete usage guidance: feed the returned tag_id into polymarket_markets/polymarket_events. This establishes a clear workflow and when to use this tool relative to alternatives, with no ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• seriea_matchesA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly/idempotent/openWorld, but the description adds substantial behavioral context: the ~1.2 MB payload, that narrowing params are ignored, the need for client-side filtering, and the exact meaning of matchSet/roundName. It also states auth is not needed and outlines the 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense with essential information: purpose, size warning, filtering instruction, return schema, and auth. Each sentence or code snippet earns its place; the formatting with a separate note and code block makes it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description fully explains the return structure, the matchweek grouping concept, and the client-side filtering requirement. It also addresses the large payload and how to source the required seasonId, making it highly complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining that matchday/round/page parameters are ignored (even though they don't exist in the schema) and clarifying the seasonId comes from seriea_seasons. This goes beyond the schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'All 380 matches for a season' and lists the included fields (scores, status, kickoff, stadium, matchday). It is season-scoped and distinguishes itself from sibling tools like seriea_seasons, seriea_standings, and seriea_teams.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides strong context: season-scoped, whole season returned, must filter client-side, and mentions seasonId comes from seriea_seasons. However, it does not explicitly name alternative tools or when not to use this one, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportmonks_fixtureA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the read-only/idempotent/open-world annotations, the description discloses that the return shape is from vendor docs and unverified, that event type_ids are numeric and require resolution via sportmonks_types, that include controls response composition, and that authentication requires a SPORTMONKS_TOKEN. These are valuable caveats for safe invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with 'One fixture' and every subsequent element—return shape, vendor caveat, example, auth note—earns its place. It is dense but not bloated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description covers the expected response shape, the unverified vendor-doc status, numeric type_id resolution via sportmonks_types, an example, and auth requirements. This is sufficient context for an agent to invoke the tool with appropriate expectations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema already fully documents both parameters (100% coverage), so baseline is 3. The description adds meaning by explaining that 'include' determines whether lineups, events, and statistics are present, and by giving a concrete example include string. This elevates understanding beyond the schema's example.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it returns a single fixture ('One fixture') and explains that the include parameter controls whether lineups, events, and statistics are returned. This distinguishes it from sibling tools like sportmonks_fixtures_by_date, which fetches multiple fixtures.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context that this is for a single fixture lookup with include-driven response richness. However, it does not explicitly mention alternatives like sportmonks_fixtures_by_date or when to prefer other sportmonks tools, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsdataio_mlb_games_by_dateA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Even though annotations declare readOnlyHint, openWorldHint, and idempotentHint, the description adds valuable behavioral context: the output shape is from vendor docs and NOT verified against a live response, so agents should treat fields as approximate. It also discloses the auth requirement (key in one of several SPORTSDATAIO_* env vars), which goes beyond the annotations and is critical for successful invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and efficiently conveys essential information: the core purpose, the return shape, a caveat about accuracy, an example, and auth notes. Every sentence earns its place, with no fluff or repetition. The format is scannable and front-loaded with the most important details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with no output schema, the description is remarkably complete. It provides the full list of expected fields, warns about the unverified shape, gives a working example, and specifies auth requirements. The caveat about inspecting the actual payload further prepares the agent for potential schema drift, making the description sufficient for confident use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage for the single `date` parameter, including format and required status. The description adds an example but no additional semantic meaning beyond what the schema states. Baseline 3 is appropriate since the schema does the heavy lifting and the description does not introduce new parameter nuances.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: 'MLB games on a date, with probable pitchers and the line.' It explicitly includes the return fields and distinguishes itself from the keyless official `mlb` provider, making the purpose and scope unambiguous. The sibling tools for other sports are implicitly differentiated by naming MLB and date.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance by noting that the keyless official `mlb` provider is 'deeper for everything except the line and the DFS layer,' implying this tool is the choice when line/DFS data is needed. It also gives a concrete example of the required date parameter, which helps the agent understand how to invoke it correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsdataio_nfl_projectionsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, idempotent, and openWorld, so the bar is lower. The description adds substantial value by disclosing the shape is from vendor docs and unverified, advising to inspect actual payload. It also notes authentication requirements and per-operator scoring differences. This is transparent and goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and efficient: a single purpose sentence, a return shape, a note, an example, and auth info. Each sentence earns its place—no fluff. The structure with 'Returns:', 'NOTE:', 'Example:', and 'Auth:' makes it scannable with all critical information front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the absence of an output schema, the description lists the exact return fields, making the payload predictable. It also covers the data reliability caveat, an example call, and authentication. Given the tool's simplicity (2 params, no nested objects), this is a complete and self-contained description that answers likely questions an agent would have.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers both parameters 100% but only describes them as 'Required — part of the URL path.' The description's example ({"season": "2023", "week": 1}) adds concrete format and type semantics, clarifying that season is a string like '2023' and week is an integer. This adds value beyond the minimal schema descriptions, though it could have explained the season format more explicitly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Projected NFL player game statistics for a week.' This is specific, identifies the resource (NFL player game statistics) and the scope (projections for a week), and naturally distinguishes it from sibling tools like sportsdataio_nfl_scores or sportsdataio_nfl_teams. The return shape and example further reinforce the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for use (projections for a week) and an example invocation. It also provides a usage hint about per-operator scoring columns ('DraftKings and FanDuel score differently, so use the matching one'). However, it does not explicitly state when not to use this tool or name alternative tools for other data types (scores, injuries, etc.), so it stops short of full exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsgameodds_sportsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the unverified nature of the return shape, advises the agent to inspect the actual payload, and states the auth key requirement. These add valuable context beyond the read-only annotations, showing strong transparency about data reliability.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with separate sections for purpose, return shape, note, example, and auth. Each section adds necessary value, and the main message is front-loaded in the first sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that this is a simple parameterless lookup tool, the description provides a full picture: it explains the purpose, the return shape (even if approximate), an example, auth requirements, and a reliability caveat. This is complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are no parameters, so the baseline is 4. The description explains that the output contains sportID values that other tools filter on, which gives meaningful context to the response. It doesn't need to explain parameter details since none exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool returns the sports covered and that the sportID field is used by other tools for filtering. This distinguishes it from sibling tools like sportsgameodds_leagues or sportsgameodds_events, which have their own specific resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies that this tool should be used to discover the sportID values needed for other sportsgameodds tools, and it provides an example. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsgameodds_statsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses that the response shape is from vendor docs, unverified against live response, and approximate. It also mentions the auth requirement (SPORTSGAMEODDS_API_KEY). This adds significant behavioral context and manages expectations about data reliability, exceeding what annotations provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded: purpose, return shape, usage warning, verification caveat, example, and auth note. Each sentence contributes unique information with no redundancy. The format uses clear sections and is appropriately sized for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the single optional parameter, no output schema, and rich annotations, the description fully carries the context. It provides the return shape, an example call, a warning about unverified vendor shape, and auth requirements. An agent would be well-equipped to decide when and how to call this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with the description 'League id.' The description adds an example with 'leagueID: "NFL"' and contextualizes it as 'NFL statistics', which helps the agent understand how to populate the parameter. This extra example goes beyond the schema's minimal description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a catalogue of statIDs that form the first segment of prop oddIDs, and returns the shape with statID, name, leagueID, and entityType. This distinguishes it from sibling tools like sportsgameodds_leagues or sportsgameodds_teams, which serve different resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs to 'Read this before constructing prop filters' and warns that guessing statIDs leads to empty results. This gives a clear when-to-use directive. However, it does not explicitly name alternative tools or conditions where this tool should not be used, so it stops short of a perfect 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• theoddsapi_historical_oddsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description adds critical behavioral details: the response is wrapped in a snapshot envelope with timestamp fields, the free tier returns 401/422, and the payload shape is unverified and approximate. This is transparent and manages expectations about reliability.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear opening purpose, a return-shape section, an important caveat, a concrete example, and an auth note. Every sentence adds value, and it is front-loaded with the core concept. It is appropriately sized for a tool with this complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description explains the return envelope and references the sibling odds shape. It also covers paid-tier restrictions, unverified data caveat, and authentication requirement. The example further anchors the parameter usage, making the tool fully understandable for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with descriptions for all parameters, so the baseline is 3. The description adds a concrete example showing how 'sport', 'date', 'regions', and 'markets' combine, which further clarifies usage. Since the schema fully documents semantics, the example is a modest but real enhancement.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this tool returns 'Odds as they stood at a past timestamp' and positions it as the 'paid-tier time machine for CLV work.' It also distinguishes itself from the sibling live call by noting the 'snapshot envelope, unlike the live call,' so the purpose is specific and differentiated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context for when to use it (past-timestamp queries, CLV work) and notes the paid-tier requirement with free-tier error codes. It implies the alternative is the live call (theoddsapi_odds) by contrasting the response shape, though it does not explicitly name other tools or state when NOT to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• twitter_tweet_countsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint), the description adds the critical 'last 7 days' time constraint, the exact return format, and the X_BEARER_TOKEN authentication requirement. This provides substantial behavioral context not present in the structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: three sentences covering purpose, return format, and authentication. It is front-loaded with the core purpose first and every sentence contributes meaningful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 4 params and no output schema, the description provides the return structure, auth needs, time scope, and use-case guidance. Combined with the read-only/idempotent annotations, this is a complete and self-sufficient description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes all 4 parameters with 100% coverage. The description adds value by specifying the default time range ('last 7 days') and confirming the query operator syntax as 'same as search,' which helps clarify the query parameter beyond the schema's basic description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns 'Post volume over time for a query' with a specific scope ('last 7 days') and distinguishes from reading posts by calling it 'the cheap way to gauge buzz without reading posts.' The verb 'Returns' and the explicit output structure make the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it ('cheap way to gauge buzz') and contrasts it with reading posts, but does not explicitly name alternative tools or state when not to use it. It gives clear context for volume-over-time queries versus actual post retrieval.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ufc_fightsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description adds valuable behavioral details: the exact response shape, that fight_final_winner is null for upcoming/drawn bouts, and that no authentication is needed. The null-winner caveat is especially helpful for avoiding incorrect inferences.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: a one-line purpose, a concise return example, a critical caveat, a usage example, and an auth note. Every sentence earns its place, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 showing a representative response structure, explaining the null winner edge case, providing a query example, and stating auth requirements. This is comprehensive for a list/fetch tool with five optional parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All five parameters are fully described in the schema, so the baseline is 3. The description adds an example call ({"limit": 10}) and clarifies that the default include resolves both corners and the winner, providing practical context beyond the schema's field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Individual bouts — both corners and the winner — back to UFC 1', which clearly states the resource (UFC bouts) and the scope (all historical fights). This distinguishes it from sibling tools like ufc_events and ufc_event_card, which handle event-level data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The tool's domain is clearly implied: it is for individual fight bouts rather than events or athletes. However, it does not explicitly name alternative tools or state when not to use this tool. The example 'Recent bouts with fighters resolved' gives a concrete use case, but no exclusions are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ufc_rankingsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses behavioral quirks beyond the annotations: the unfilterable nature verified by the tool creator, the ~200-row set requiring pagination, and the meaning of fields like category and previous rank movement. This goes well beyond readOnlyHint/idempotentHint/openWorldHint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized into compact sections: summary, Returns, WARNING, Example, Auth. Every sentence adds value and there is no redundancy with the schema or annotations.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 listing return fields and their semantics, explaining category and rank movement, and describing the resolution path to names. It also covers limitations, alternatives, pagination, and auth status, making it fully self-contained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptive parameter docs for sort, limit, and offset. The description adds an example ({"limit": 50}) and implies paging behavior, but does not materially expand on the schema's already clear parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Divisional rankings, including pound-for-pound, with each fighter's previous position', giving a specific verb+resource. It distinguishes itself from related tools like ufc_athlete and ufc_search_athletes by referencing them as alternatives for different needs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly warns that the collection CANNOT be filtered, noting that `filter[fightmetric_id]` returns 0 rows rather than an error, and instructs to page the whole set and match client-side. It names ufc_athlete as the alternative for a single fighter's current ranking, providing clear when-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• ufc_search_athletesA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover read-only, open-world, and idempotent behavior. The description adds context beyond annotations: no auth needed, the exact response shape, and the instruction to keep both the uuid and fightmetric_id for downstream lookups. This is useful behavioral disclosure, though it omits potential edge cases 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured with clear sections: purpose, return format, example, and auth. Every sentence adds value, including the return schema guidance and example, with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 explains the return structure and advises on how to use the returned IDs. It covers auth, provides an example, and disambiguates from sibling tools. For a read-only search tool, this is complete and actionable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description adds a concrete example (searching by surname 'Adesanya') and reinforces the operator default ('CONTAINS is the useful default'), which goes beyond the schema's generic parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description specifies a clear verb and resource ('Find fighters by partial name') and explicitly differentiates from sibling tools by stating 'Start here — every other athlete tool needs an exact title or an id.' This gives the agent an unambiguous understanding of the tool's unique role.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit 'when to use' guidance via 'Start here' and explains the alternative (other athlete tools require exact title or id). The example search and auth note further clarify practical usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_game_stat_categoriesA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Exceeds the readOnlyHint/idempotentHint annotations by disclosing the approximate return shape (with example structure), explicitly warning that the shape is unverified against a live response, and noting the auth requirements. This level of honesty about data quality and the caveat to 'inspect the actual payload' is exceptional transparency. No contradiction with 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Despite its length, every sentence earns its place: returns shape, unverified-data warning, a concrete example, and auth requirements. Clear sections (Returns, NOTE, Example, Auth) make it scannable. It conveys a substantial amount of valuable information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only lookup tool with no output schema, the description is thorough: it explains the return value, provides the nested shape, flags uncertainty, gives an example, and documents auth — covering all reasonable issues an agent would need to use it. The description fully compensates for the lack of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the gameKey and format params, providing a baseline of 3. The description adds value through a concrete example ("Example: NFL stat categories {\"gameKey\": \"nfl\"}") and clarifies the format param by noting it should be left as 'json.' The description enriches the required param's meaning by connecting it to the resource path.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb-resource pairing: it returns every stat category and its id for a game, serving as 'the lookup that makes scoring settings and player stats readable.' It effectively differentiates itself from siblings by explaining its role as the decoding key for bare stat_ids, which no other tool description claims.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use the tool — pointing out that 'Player stats and league scoring both refer to bare stat_ids' so this lookup is necessary to interpret them. However, it doesn't explicitly name alternatives or give 'use when/when not to use' guidance relative to sibling tools, though the practical use case is well implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• yahoo_leagueA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, idempotent behavior, and the description adds valuable caveats: the return shape is from vendor docs and unverified, auth requires a key in specific environment variables, and the note to inspect actual payloads. This is beyond what annotations provide and is critical for an agent to avoid relying on unverified field names.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with purpose, then provides return shape, a critical caveat, an example, and auth requirements. Each sentence serves a distinct purpose without redundancy. The formatting uses line breaks for readability, making it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of an output schema, the description fully details the expected return shape, including specific field names and type hints. It also covers verification status, auth prerequisites, and a usage example. It is complete enough for an agent to invoke the tool correctly and interpret results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes both parameters (format and leagueKey) with 100% coverage, so the baseline is 3. The description adds a concrete example ('449.l.12345'), explains that leagueKey comes from yahoo_my_leagues, and implies its role as part of the URL path, adding meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'League metadata: name, size, scoring type, current week, and the season's week range.' This is specific and distinguishes it from sibling tools like yahoo_league_settings or yahoo_league_standings, which focus on other aspects. The mention that 'current_week drives every week-scoped call below' further clarifies its role as a foundational metadata lookup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by stating that 'current_week drives every week-scoped call below,' which signals that this tool should be used first to obtain the current week. It also provides an example and notes the leagueKey comes from yahoo_my_leagues, giving workflow context. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espnfantasy_league_historyA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses important behavior beyond annotations: it returns a single-element ARRAY (not an object), 404s when the league lacks history, and provides a verified example of that failure. It also mentions auth requirements and that a cookie unlocks more data. None of this contradicts annotations (readOnlyHint, openWorldHint, idempotentHint) — it complements them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections (purpose, prerequisites, return format, example, auth) and front-loads the core purpose. It's slightly verbose with the 'verified: public league 1234...' detail, but every part earns its place given the complexity of the tool's behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description thoroughly explains the return structure ('Returns: [{id, seasonId, settings, teams, status, …}] — ARRAY wrapper'), error behavior (404 and fallback), how to verify availability, and authentication. It leaves no ambiguity about how to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameters are already documented. The description adds meaningful semantics: explains that omitting seasonId returns every season with history, describes the view as 'same vocabulary as the seasons path,' and provides a concrete example request. This goes beyond the schema's basic descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool retrieves pre-2018 seasons and cross-season history via the leagueHistory path. It uses a specific verb (returns history) and resource (leagueHistory path), and distinguishes itself from sibling tools like espnfantasy_league and espnfantasy_status by focusing on historical data and returning an array.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit when-to-use guidance is provided: 'Only works for leagues that HAVE history — check espnfantasy_status.status.previousSeasons first; an empty list there means this returns 404.' It also names an alternative ('fall back to the seasons path') and explains the condition for using that alternative. This is excellent usage differentiation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espn_site_callA
  4.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description adds useful context like 'Auth: none needed', return type (JSON object), and that operations are dynamic. It does not mention potential error handling or rate limits, but for a read-only gateway with strong annotations, this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact yet information-dense, covering purpose, required inputs, coverage scope, alternatives, discovery mechanism, return type, and auth in a clear flow. Every sentence adds value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description provides sufficient context for a generic gateway tool: how to discover operations, what path params are expected, and which sibling tools cover alternative needs. This makes the tool usable without additional resources.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description enriches the schema by explaining that `path_params` must include at least `sport` and `league` with slug examples (football/nfl, basketball/nba) and optional IDs like teamId/athleteId. It also reinforces the schema's `query_params` description, providing practical guidance beyond the property definitions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a gateway to the ESPN site API resource families, enumerating specific data types (team detail, rosters, schedules, injuries, etc.). It explicitly distinguishes from sibling tools by directing athlete profiles/game-logs/splits to espn_web_call or espn_core_call.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides concrete instructions on how to supply `operation`, `path_params` (with sport+league and id), and optional `query_params`. Explicitly names alternatives for different data needs (espn_web_call, espn_core_call) and directs users to browse the operations catalogue for valid operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fpl_playersA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint, and the description adds substantial context beyond those: the large response size warning, the fact that the data is trimmed from 105 to 22 fields, the upstream blob size (362k tokens), the meaning of status codes, and the unit convention for now_cost. This gives the agent a clear behavioral model of what to expect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-structured, with a clear statement of purpose, a prominent size warning, a detailed return shape, unit/status explanations, and an auth note. The 'Example: Every player, key fields' line is slightly redundant filler, but the rest of the content is information-dense and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 full burden of documenting return values. It does this thoroughly by listing all 22 fields, explaining the now_cost unit, defining status codes, and warning about the large token count. This is complete enough for a zero-parameter bulk read tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema is empty and coverage is 100%. The description doesn't need to explain parameter meaning, and the baseline of 4 for zero-parameter tools applies. The description does not introduce any parameter-related ambiguity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Every FPL player with price, form, ownership, expected goals and availability,' using a specific verb ('Every FPL player' as the resource) and a precise field list. It also explicitly distinguishes itself from fpl_player_detail by directing users to that tool for one player's depth, which clearly separates its scope from a close sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use this tool (for all players with key fields) and when not to (for one player's depth, use fpl_player_detail). It also provides a practical usage guideline by warning about the large token size (~65k tokens) and mentions authentication prerequisites (works without key, cookie unlocks more).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• supercoach_playersA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/openWorld/idempotent annotations, the description adds substantial behavioral detail: the large payload size (~1–3 MB), the closed embed set (anything else is ignored), the guidance to use ppts1 over ppts (with fallback behavior), and the draft-mode additions. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence adds value: overview, size warning, usage guidance, return shape, field guidance, draft mode, example, and auth. It is well-structured and front-loaded with the most critical information, making it appropriately dense for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 5 parameters, no output schema, and large response, the description is exceptionally complete. It covers size, embed constraints, ppts1/ppts semantics, year edge cases, round requirements, draft mode, and gives a concrete example. The lack of an output schema is fully compensated.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the schema covers all parameters, the description adds significant meaning: round is 'REQUIRED in practice' despite a default, year is not always the calendar year (with fallback instructions), the embed closed set is explicitly listed, and mode=draft adds fields. This goes beyond the schema's baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'THE feed' and explicitly states the tool returns 'every player's full snapshot for one round' with a detailed list of fields. It is a specific verb ('feed') + resource ('players') + scope ('one round'), and it distinguishes itself from sibling tools like supercoach_player (single player) by covering all players.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage scenarios: passing `round` for a forward snapshot, looping rounds with `embed=player_match_stats` for a historical series, and notes the closed embed set. It does not explicitly name alternative sibling tools or state when not to use this tool, but the context is strongly implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• wta_tournamentsA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description discloses pagination behavior (list spans all years), the full response structure, and the cross-tool navigation pattern. This adds significant behavioral context that is not available from annotations alone.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with a clear introduction, a response shape, usage guidance, an example, and auth info. However, the field list is repeated almost identically in the opening sentence and the 'Returns:' section, which is mildly redundant but not detrimental.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description fully covers return values, pagination, and how to use results with related tools. It also addresses auth and provides an example, making it complete for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already defines page and pageSize with descriptions and defaults (100% coverage). The description adds value by explaining pagination semantics ('the list spans all years') and providing an explicit example with pageSize: 50, which goes beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as 'The WTA tournament calendar' and enumerates the exact fields returned. It also distinguishes itself from sibling tools by explicitly stating that a row's tournamentGroup.id + year should be used for wta_tournament / wta_tournament_matches, making its role as a list/calendar distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage guidance: 'Page through with page/pageSize (the list spans all years)' and explains how to use the output to access related tools ('Take a row's tournamentGroup.id + year for wta_tournament / wta_tournament_matches'). It also notes that no auth is needed, setting expectations for invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• betfair_markets_by_eventA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint/idempotentHint annotations, the description reveals critical behavior: the route 'STRIPS exchange prices (runners come back without the exchange block)' and '400s on multi-id batches'. Also notes 'Auth: none needed' and provides a probed date, adding confidence and specifics.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the purpose and key limitations, followed by a concise Returns block and Auth line. Every sentence adds value: alternatives, error behavior, and response shape. No filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 8 params but only 1 required, the description fully covers selection and invocation: how to obtain eventIds, what to expect in the response (explicit Returns structure), and how it fits with sibling tools. The absence of an output schema is compensated by the Returns block.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description enhances this by clarifying the eventIds source ('from betfair_navigation EVENT nodes') and emphasizing the one-id-per-call constraint. It also warns that despite the types default including RUNNER_EXCHANGE_PRICES_BEST, exchange prices are stripped anyway.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Market STRUCTURE for an event (market ids, names, runners)'. It uses a specific verb and resource, and explicitly differentiates from siblings by directing users to betfair_market_prices for prices and betfair_navigation for bulk discovery.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: tells users to use this tool for market structure, not for prices (pointing to betfair_market_prices) nor for bulk discovery (pointing to betfair_navigation). Also warns against multi-id batches ('400s on multi-id batches') and advises preferring one event id per call.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• espn_scoreboardA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the tool is known to be safe and non-mutating. The description adds valuable behavioral context beyond annotations: the return structure, that no auth is needed, and that it can operate on today's or a specified date. No contradictions found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is succinct and well-structured: a one-sentence purpose, a return shape, a short example, and an auth note. Every part earns its place, and it avoids unnecessary fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even though there is no output schema, the description explicitly states the return structure and gives an example. It also mentions the key input parameters and their slug format. For a relatively simple scoreboard tool, this is sufficiently complete for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 enhances parameter understanding by explaining that sport and league are slugs (with examples like football/nfl) and provides a concrete usage example. This adds useful clarity without overdoing it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns a scoreboard for one league with status, clock, score, and event IDs. It also distinguishes itself from siblings by noting it is the fastest way to get event IDs needed by espn_game_summary / espn_core_call, making it specifically actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit guidance on when to use this tool: to get event IDs for a league, especially before calling espn_game_summary or espn_core_call. It also clarifies the slug format for sport and league and includes an example, which helps an agent decide when this is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• euroleague_gamesA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and idempotentHint, but the description adds substantial context: return field structure, the local/road naming convention, identifier format, auth requirements, and the crucial gameCode-vs-uuid gotcha. This goes well 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Although longer than typical, the description is tightly structured and every sentence earns its place: purpose, return schema, gotcha, example, auth. It is front-loaded with the core purpose and contains no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  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 explains the return shape with a detailed structure and example. It also covers size/pagination concerns, field naming, and authentication, making it complete for a listing tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds usage context beyond the schema by explaining why limit/roundNumber matter (size ~800 KB) and providing an example call, which helps the agent choose and combine parameters correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns 'Games in a season with scores, venue and officials,' which is a specific verb+resource. It distinguishes itself from sibling tools like euroleague_game by noting that per-game tools should use gameCode, not the uuid returned here.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly advises to 'pass a limit or filter by round' due to the ~800 KB size, and warns to 'use gameCode (an int) for the per-game tools, not the uuid.' This gives clear when-to-use and when-not-to-use guidance relative to alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• golfcourseapi_searchA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint, openWorldHint, and idempotentHint, which already signal safe read-only behavior. The description adds valuable context beyond annotations: it warns that the response shape is from vendor docs and unverified, advises inspecting the actual payload, and notes the auth key requirement—key behavioral caveats that an agent needs before relying on the response.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and efficiently organized: one-line purpose, return shape, caveat about unverified shape, example, and auth note. Every sentence earns its place and provides essential operational info without fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity (single required param, simple search semantics), the description covers all key aspects: purpose, return shape, limitations, example, and auth. The explicit caveat about unverified vendor shape is crucial for a tool without a live key, and the pointer to golfcourseapi_course completes the necessary context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (only one param, search_query, described as 'Course or club name'), so the schema already documents the parameter. The description adds a concrete example ('Pebble Beach') and further explains the parameter semantics ('name or club'), which supplements the schema without needing to restate everything. Baseline of 3 applies, but the example and the name/club clarification add modest value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states a specific action ('Search the course catalogue') with clear scope (by name or club), and explicitly differentiates from sibling golfcourseapi_course by noting this returns summary only while per-hole data needs the sibling. The verb+resource+scope combination is precise.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says when to use it (to search summary info) and when not to (per-hole data needs golfcourseapi_course), effectively naming the alternative tool. It also provides an example call and notes the auth requirement (GOLFCOURSE_API_KEY), giving clear contextual guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nba_scheduleA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly, openWorld, idempotent), the description reveals the payload size (~8 MB), the exact return structure with leagueSchedule/seasonYear/gameDates, and that no authentication is needed. These are concrete behavioral facts that help an agent anticipate cost and parse output.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences, each with a distinct purpose: scope, performance warning, return format, and auth. It is front-loaded with the core purpose and contains no redundant phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a simple no-input data retrieval, and the description covers all essential aspects: what data is returned, how large the response is, when to use an alternative, and the response shape. This is complete for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With zero parameters, the input schema is already complete. The description adds no parameter-specific detail, which is appropriate given the tool takes no arguments. Per the rubric, a baseline of 4 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Full league schedule for the current season (every game, date, broadcasters, arena)' which is a specific verb-resource combination. It also differentiates from nba_scoreboard_today by recommendation, making the tool's niche clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Large payload (~8 MB) — prefer nba_scoreboard_today for just today,' naming an alternative and giving a clear condition for not using this tool. This provides explicit when-not/alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• openligadb_season_matchesA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds a size warning (~550 KB) and explicit response schema, auth requirement, and example, going beyond the readOnly/idempotent/openWorld annotations. No contradictory behavioral claims.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Front-loaded with purpose and size warning; the Returns block is efficiently structured and the example is compact. Every sentence contributes value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers purpose, size, alternative, auth, example, and full return structure. Without an output schema, the description takes on that responsibility and fulfills it completely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, providing baseline 3. The description's concrete example (league:'bl1', season:'2024') adds a real-world mapping that the schema's terse descriptions don't fully convey, earning an extra point.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns every match in a league season with results. It distinguishes itself from the sibling matchday tool by warning about large size and recommending the matchday tool for smaller scope. The Returns: block specifies exact content.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says 'prefer the matchday tool' for the large payload, indicating when not to use this tool. The example shows how to request a whole Bundesliga season, and 'Auth: none needed' covers prerequisites. This provides clear when-to-use context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sportsdata_session_statsA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful context: data comes from local counters, is session-specific, and 'Nothing here has been sent anywhere,' assuring privacy and non-mutation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each serving a distinct purpose: what it reports, how to interpret signs of misbehavior, and a privacy/scope note. No filler, well-structured, and appropriate length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no parameters and an output schema present, the description covers all essential information: purpose, usage guidance, and behavioral context. It is fully sufficient for an agent to decide when to use the tool and what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool takes no parameters and the schema is empty (100% coverage). No parameter description is needed, and the baseline for zero-parameter tools applies, so no additional value can be added here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool reports: per-tool call counts, error rates, error codes, latency buckets, and empty-result counts. It explicitly scopes to 'THIS session', which distinguishes it from the many sports-data sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description says 'Useful when a tool seems to be misbehaving' and provides concrete interpretation examples (AUTH_REQUIRED means missing key, high empty count means no upstream data). This gives the agent explicit guidance on when to invoke it and how to interpret results.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• dabble_competitionsA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  While annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, the description adds valuable behavioral context: case-sensitive exact matching, empty results for non-existent names, inclusion of non-active competitions, and the full response shape. These details go beyond the annotations and meaningfully inform the agent's expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence serves a distinct purpose: describing the primary lookup modes, warning about the bare endpoint, pointing to the alternative tool, specifying the return format, and noting auth requirements. The structure is front-loaded and well-organized, with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even though there is no output schema, the description provides the exact return structure, edge-case behavior (empty results), and a performance warning about the unfiltered endpoint. Combined with the annotations and parameter semantics, the description is fully sufficient for correct tool selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description significantly enriches both parameters. It clarifies that 'name' is exact and case-sensitive with examples (e.g., 'AFL' alone returns nothing), explains that 'sportId' includes non-active competitions, and warns that at least one filter is needed despite the schema listing zero required parameters. This compensates for schema optionality and prevents misuse.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool looks up competitions by exact name OR lists every competition for a sport, with a specific verb-resource pairing. It explicitly distinguishes itself from dabble_active_competitions by noting the preference for browsing currently-bettable comps, making its purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use contexts: exact name lookups or broad sport-wide listings. It also warns against calling without filters (the ~38 MB / 142k-row firehose) and recommends dabble_active_competitions as an alternative, providing clear usage boundaries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• nba_scoreboard_todayA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable behavioral context: the live CDN source, the return structure, a concrete example, and 'Auth: none needed' – all beyond what annotations provide, without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise: a clear opening sentence, a return type, an example, and an auth note. Every sentence adds value, and the most important information (purpose and how to use the results) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no parameters and no output schema, the description fully compensates by providing the return shape, example, auth requirement, and relationship to sibling tools. It is complete for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema is empty, so schema description coverage is 100% vacuously. The description further clarifies that no parameters are required and provides the return structure and example, exceeding the baseline for a 0-parameter tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides today's games from the live CDN scoreboard, including matchups, scores, period/clock state, and game IDs. It also distinguishes itself from siblings by explicitly positioning it as the fastest way to get gameIds for nba_boxscore/nba_playbyplay.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly names nba_boxscore and nba_playbyplay as consumers of the gameId, giving clear guidance on when to use this tool. The 'today' scope also differentiates it from schedule or historical tools, and the reference to 'fastest way' indicates a preferred choice for this specific purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.