Server Quality Checklist

Tool Scores

• get_team_scheduleA
  4.2/5.0
  Behavior4/5

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

  The description discloses return details including scheduled, in-progress, and completed matches with opponent, date, score, and status. Since annotations already mark it as read-only and idempotent, this adds useful behavioral context beyond the structured metadata. However, it does not mention pagination or potential errors, which is acceptable for a simple 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 brief and well-organized: purpose, return summary, and parameter explanation. Every sentence contributes 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?

  The tool is simple (one parameter, output schema exists), and the description covers its purpose, return content, and parameter format. The questionable example team ID is a minor completeness gap, but overall it is adequate for agent 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?

  With schema description coverage at 0%, the description compensates by explaining team_id as an ESPN numeric ID with an example. The example '18418' is attributed to Atlanta United FC, which is inconsistent with the Women's Super League context, slightly undermining clarity. Still, it clearly communicates the expected format.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 all matches for a single Women's Super League team in the current season,' which specifies a distinct action and resource. This distinguishes it from siblings like get_scoreboard (all teams) and get_match_details (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 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 team's schedule but does not explicitly state when to use it over alternatives. It lacks any mention of sibling tools or cases where another tool would be more appropriate, so it provides only indirect guidance.

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

• get_adjusted_points_per_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, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds meaningful behavioral context by explaining the exact calculation (`avg_opponent_ppg / league_average_ppg`) and the interpretation of results relative to raw PPG, which goes 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.

  Conciseness5/5

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

  The description is short and front-loaded with the main action. The formula explanation is compact and directly supports understanding, with no filler. The Args section is minimal and efficiently captures the only parameter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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, single-parameter tool with rich annotations and an output schema, the description covers all essential context: what it returns, how the adjustment works, and how to interpret the result. No major information is missing for an agent to select and invoke the tool correctly.

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

  Parameters3/5

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

  The schema has one `team_id` property with no description (0% schema coverage). The description compensates with 'ESPN numeric team ID,' which clarifies the expected value format and source. However, it is brief and could include more detail about constraints or data requirements.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Get a team's raw points-per-game alongside an opponent-quality-adjusted PPG,' using a specific verb and resource. It clearly differentiates from sibling tools like get_strength_of_schedule by focusing on points-per-game adjustment rather than schedule strength alone.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents 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 explains what the tool does and the adjustment formula, giving context for when it would be useful. It does not explicitly name alternative tools or state when-not-to-use, but the unique purpose provides implicit guidance, and the sibling tools serve distinctly different goals.

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

• get_newsA
  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 non-destructive behavior. The description adds useful context by specifying the return content (headline, publication date, summary, link to ESPN story) and the 'recent' temporal scope, which are not evident 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.

  Conciseness5/5

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

  The description is concise and front-loaded: one sentence states purpose, one sentence lists return fields, and one line documents the arg. 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 tool with a single optional parameter, rich annotations, and an output schema, the description fully covers purpose, return value shape, and parameter semantics. No critical information 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?

  With 0% schema description coverage, the description compensates by explaining the single parameter: 'Maximum number of articles to return (default 10).' It adds semantic meaning beyond the schema's type/default by clarifying that limit controls the maximum article count.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 and resource: 'Get recent Women's Super League news articles.' It clearly identifies the tool's scope (WSL news) and differentiates it from sibling tools like get_standings and get_teams by focusing on news articles.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 need recent WSL news) but does not explicitly state when to prefer it over alternatives or when not to use it. There is no exclusionary guidance, but the purpose is clear enough 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.

• get_rosterA
  4.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 destructiveHint=false, covering the safety profile. The description adds that it returns active roster data and the specific player attributes, but does not discuss behavior like pagination or rate limits. 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 compact: three sentences plus an Args section. It front-loads the purpose, then lists return fields and prerequisite info, with no redundant or filler content. Every sentence contributes meaning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 an output schema, the description covers the essential context: what the tool does, return fields, how to obtain the required team_id, and an example. Nothing critical is missing.

  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 input schema has no description for team_id (0% coverage), but the tool description fully compensates by explaining team_id is an ESPN numeric team ID and providing a concrete example ('18418' for Atlanta United FC). It also cross-references get_teams as the source. This completely clarifies the 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 gets the active roster for a Women's Super League team, and lists the returned fields (jersey number, name, position, citizenship, age). This verb+resource+scope combination distinguishes it from sibling tools like get_teams (list teams) or get_team (single team details).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents 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 instructing to use the team ID returned by get_teams, and includes an example team ID. It does not explicitly exclude alternative tools, but for a roster lookup this is sufficient context.

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

• get_standingsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare the operation read-only, open-world, idempotent, and non-destructive. The description adds valuable specifics: a 14-team table ordered by points descending, with win/loss/tie record, goals for/against, and goal differential. This 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 two concise sentences. The first states the action, the second details the output structure. No wasted words or redundant 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 the tool's simplicity (zero params), existing output schema, and annotations covering safety, the description covers all key aspects: league, table size, ordering, and statistics. Nothing significant 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 schema coverage is complete. The description appropriately says nothing about parameters. Baseline for zero-param 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 the tool retrieves the current Women's Super League standings with a specific resource and verb. It distinguishes itself from siblings like get_scoreboard (scores) and get_team_schedule (fixtures) by focusing on the league table.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents 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 for standings) but does not explicitly mention exclusions or alternatives. For a zero-parameter read-only tool, the purpose is self-evident, and the lack of explicit alternative guidance is acceptable.

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

• get_teamsA
  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 non-destructive behavior. The description adds value by disclosing that only active teams are returned and that the output is a numbered list with specific fields, which goes beyond the annotation-only 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 sentences. The first states the action, the second the return format, the third provides a usage pointer. 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.

  Completeness5/5

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

  For a zero-parameter list endpoint, this description is complete. It covers what is returned (ID, name, abbreviation, home city), notes the 'active' filter, and directs traffic to get_team for follow-up. With full annotations and an output schema present, no additional behavioral details are necessary.

  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, so the description rightly omits parameter details. The baseline of 4 for zero-parameter tools applies, and the description correctly focuses on output and 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 clearly states the tool's function: 'Get all active Women's Super League teams.' It specifies the resource (teams), scope (all active, WSL), and distinguishes itself from the sibling get_team by positioning this as the list-all tool and directing users to use get_team for details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 guidance to use the returned ID or abbreviation with get_team for detailed info, providing a clear alternative. It doesn't discuss exclusions for other sibling tools, but for a simple list-fetching tool this context is sufficient.

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

• get_match_detailsA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare read-only, idempotent, non-destructive behavior. The description adds the return payload details (score, venue, attendance, events) and the expected match_id format, offering 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.

  Conciseness5/5

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

  Two sentences plus an Args block, front-loaded with the purpose, no redundant explanations.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 lookup, the description covers purpose, parameter source/format, and return content. With output schema present and rich annotations, nothing essential is missing.

  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 only says 'Match Id' string. The description specifies it as an 'ESPN numeric event ID' with example '401853883' and explains where to obtain it, fully compensating for the 0% schema description 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 'Get detailed information for a single Women's Super League match' and enumerates return content, distinguishing it from list-oriented siblings like get_scoreboard and get_team_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 explicitly instructs to 'Use the match ID returned by get_scoreboard or get_team_schedule,' providing context for when this tool is appropriate. It lacks an explicit 'when-not' exclusion, but the purpose and source references imply the alternative tools for other scenarios.

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

• get_scoreboardA
  4.6/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 additional details about defaulting to the current matchweek and the end_date dependency provide useful behavioral context. 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 concise and well-structured: a summary line, then a clear conditional breakdown, then an args section with precise details. Every sentence adds 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?

  With an output schema present, return-value specifics are not needed. The description covers all argument combinations, date formats, and dependencies, making the tool fully comprehensible for an agent.

  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?

  Despite 0% schema coverage, the description fully documents both parameters, including the YYYYMMDD format, optionality, and the requirement that end_date needs date. This compensates completely for the schema's lack of 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 uses a specific verb ('Get') and clearly identifies the resource ('Women's Super League match scores and status') and the scope (date or date range). This distinguishes it from siblings like get_match_details and get_team_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 clearly explains when to call the tool with no arguments, with only date, and with both date and end_date, including the inclusive-range behavior. It does not explicitly mention alternatives, but the usage contexts are unambiguous.

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

• get_strength_of_scheduleA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context by specifying it computes average points-per-game of opponents in completed matches and returns a per-opponent breakdown, going 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 front-loaded with the core purpose, followed by return details and a use case. It avoids fluff and includes only valuable information, with the Args section providing a clear parameter explanation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 a full output schema and rich annotations, the description is complete. It covers purpose, scope, parameter format, and suggests when to use it, leaving no significant gaps.

  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 0%, but the description fully compensates by explaining team_id as an 'ESPN numeric team ID' with a concrete example ('18418' for Atlanta United FC). This gives the agent all necessary context to supply the parameter 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 a specific verb and resource: 'Get a team's strength of schedule based on opponents already faced.' It further defines the output as average points-per-game plus a per-opponent breakdown, distinguishing it from sibling tools like get_standings or get_team_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 gives explicit usage context: 'Useful early in the season for "who has played the tougher schedule so far?" questions.' It does not mention exclusions or alternatives explicitly, but the context is clear enough for selection.

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

• get_teamA
  4.6/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 useful behavioral context by stating what information is returned ('display name, abbreviation, and location') and clarifying the ID source, 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: a purpose sentence, a return-content sentence, and an Args section. 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.

  Completeness5/5

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

  With a single parameter, an output schema present, and comprehensive annotations, the description provides all necessary context for correct selection and invocation. The tool is simple, and the description covers purpose, parameter, and return expectations.

  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 has 0% description coverage for team_id, but the description fully compensates by explaining 'ESPN numeric team ID' and providing an example ('18418' for Atlanta United FC). This clearly conveys both meaning and format.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 details for a specific Women's Super League team' with a specific verb and resource. It distinguishes from the sibling get_teams by emphasizing 'specific', implying get_teams is for lists.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 explicit context: 'Use the numeric ID returned by get_teams' establishes a prerequisite and ties it to the sibling tool. However, it does not explicitly state when not to use other alternatives, though this is implied by 'specific'.

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

• get_results_by_opponent_tierA
  4.8/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 destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail: tiers are derived from live league standings, and tier_size has constraints (minimum 1, 2*tier_size <= league size). This goes beyond the annotations and helps the agent understand how the tool behaves at runtime.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 sentence states the purpose, followed by a brief explanation of tier derivation, a use-case rationale, and an Args section. Every sentence contributes unique information; there is no redundancy or 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 only 2 parameters, an output schema, and clear annotations, the description fully covers the tool's behavior. It explains the tier logic, constraints, and provides a comparison to manual scanning, which together give an agent complete context for 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?

  With 0% schema description coverage, the description must fully explain parameters. It does: team_id is identified as an ESPN numeric team ID, and tier_size is explained with its default value and validation constraints. This adds rich meaning beyond the bare schema property 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 opens with a specific verb and resource: 'Get a team's W-L-T splits against current top-tier, middle, and bottom-tier teams.' This clearly states what the tool does and uniquely distinguishes it from sibling tools like get_standings or get_team_schedule by focusing on opponent-tier splits. The purpose is precise and not tautological.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents 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 contextual use case: 'Lets you ask "how does this team do against the top of the table?" without scanning every result manually.' This implies when to use the tool, but it does not explicitly name alternative tools or state when not to use it. Because it gives meaningful usage context without exclusions, 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.