Server Quality Checklist

Tool Scores

• get_adjusted_points_per_gameA
  4.4/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 destructiveHint=false, covering the safety profile. The description adds useful behavioral detail beyond annotations: the exact formula for adjusted PPG ('avg_opponent_ppg / league_average_ppg') and the interpretive meaning of values above raw PPG. This is transparent about how the tool computes and what the result signifies.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 opening sentence states the purpose, followed by a brief formula explanation and an Args section. Every sentence adds value—no filler or repetition. It 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 an output schema exists, the description does not need to detail return values. It explains the calculation, interpretation, and the single parameter. The only minor gap is not explaining where to obtain a valid team_id, but this is likely covered by the get_teams sibling tool. Overall, it is sufficiently complete for a simple read-only metric 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 only defines team_id as a required string with no description (0% schema coverage). The description compensates by documenting the parameter: 'team_id: ESPN numeric team ID.' This adds clarity about the format and source, though it doesn't specify how to obtain the ID or that it should match team IDs from get_teams. Still, it is sufficient for the single 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 specific function: 'Get a team's raw points-per-game alongside an opponent-quality-adjusted PPG.' This uses a specific verb ('get') and identifies the resource (team's PPG) and the distinctive adjustment (opponent-quality). It distinguishes itself from siblings like get_strength_of_schedule and get_team by focusing on the adjusted PPG metric.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents 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 raw and opponent-adjusted PPG) and provides context for interpreting the adjusted value (higher than raw indicates a tougher schedule). However, it does not explicitly name alternatives or state when not to use it, 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.

• get_newsA
  4.4/5.0
  Behavior4/5

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

  Annotations already establish that this is a read-only, idempotent, non-destructive operation, so the description does not need to restate that. The description adds value by disclosing the return structure (headline, publication date, summary, link to ESPN) and the default limit, which goes beyond the schema. However, it does not mention any potential variability, such as the number of articles when 'recent' is ambiguous or possible downtime, but these are minor given the 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 concise and well-structured. It opens with a clear purpose statement, follows with the return details, and ends with a parameter explanation. Each sentence earns its place without redundant filler. The use of an 'Args:' section makes the parameter documentation 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?

  The tool is simple with one optional parameter and an output schema, and the description covers the purpose, return fields, and parameter semantics. Annotations provide the safety and idempotency profile. No further details like authentication or rate limits are necessary for a read-only news-fetching tool, making the description 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.

  Parameters5/5

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

  Schema description coverage is 0%, so the description carries the full burden for explaining parameters. The description provides clear semantics: 'limit: Maximum number of articles to return (default 10).' This explains both the purpose of the parameter and its default value, which is not available in the schema beyond the default attribute. The explanation is precise and sufficient for a single 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 verb and resource: 'Get recent MLS news articles.' This distinguishes it from sibling tools that focus on teams, scores, rosters, schedules, and standings, as news articles are a distinct resource. The specificity of 'recent MLS news' leaves no ambiguity about what the tool 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 description implies the tool should be used when a user wants recent MLS news, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. While the sibling tools are clearly different in topic, there is no direct guidance such as 'for scores, use get_scoreboard' or 'when you need news, use get_news.' The usage context is inferred rather than explicitly provided.

  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
  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, so the agent understands it's a safe read. The description adds the 'active roster' scoping detail and the source of team_id, 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 and front-loaded with the main purpose. It includes a minimal Args section with no redundant 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?

  For a simple read-only tool with one parameter, clear annotations, and an output schema, the description covers purpose, usage, and parameter semantics sufficiently. It leaves no critical gaps for selection or 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?

  The input schema provides no description for team_id, so the description must compensate. It clearly explains the parameter as an ESPN numeric team ID, gives a concrete example, and directs users to get_teams for the correct value—fully covering the parameter 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 opening 'Get the active roster for an MLS team' is a clear verb+resource statement. It doesn't explicitly distinguish from sibling get_team, but 'roster' is specific enough and the mention of get_teams provides 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 explicitly instructs to use the team ID returned by get_teams, establishing a clear prerequisite and workflow. It doesn't discuss when not to use it, but the context implies this is the roster-specific tool.

  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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false). The description adds useful behavioral context by specifying the response includes score, venue, attendance, and a chronological list of key events. 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 appropriately sized and front-loaded: purpose, return payload, usage, and parameter details in a compact structure. Every sentence earns its place with no filler or redundant restating of 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?

  With one parameter, clear parameter semantics, and an output schema present, the description provides complete contextual coverage. It covers what the tool does, what it returns, and how to obtain the required ID, while annotations handle the safety profile.

  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 that match_id is an ESPN numeric event ID and providing a concrete example. It also tells the agent where to obtain the ID, which is exactly what is needed to populate the sole 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 opens with 'Get detailed information for a single MLS match', which is a specific verb+resource statement. It immediately lists returned fields (score, venue, attendance, key events), clearly distinguishing it from sibling listing tools 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?

  Explicitly instructs to use the match ID returned by get_scoreboard or get_team_schedule, giving clear context for when to invoke this tool. It does not state explicit exclusions, so it falls short of a 5, but the guidance is actionable and helpful.

  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.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context beyond annotations by explaining that tiers derive from live standings and the tier_size constraint, which is not in the schema or 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 well-structured with a clear first sentence, an explanatory paragraph, and an Args list. Every sentence contributes value—no fluff—and it is appropriately sized 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?

  Given the output schema exists, return values don't need explanation. The description covers all necessary context: purpose, tier logic, parameter constraints, and the live standings dependency. It is complete for a read-only reporting tool with only 2 parameters.

  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 description coverage is 0%, but the description fully compensates with an Args section explaining both team_id and tier_size, including the default of 5 and the constraint 2*tier_size <= league size. This adds meaning the schema lacks.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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+scope: 'Get a team's W-L-T splits against current top-tier, middle, and bottom-tier teams.' This clearly distinguishes it from siblings like get_team_schedule or get_standings by focusing on opponent tier splits.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents 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 use case ('how does this team do against the top of the table?') and contrasts with manual scanning, implying when to use it. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for a complementary tool.

  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, idempotentHint, and destructiveHint=false, which cover the safety profile. The description adds meaningful behavioral context beyond annotations, such as the 'current matchweek' default behavior, the inclusive range semantics, and the requirement that end_date depends on date. 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 and well-structured: a one-sentence summary followed by bullet-like argument behavior and an Args list. Every sentence adds value, with no repetition of schema details 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?

  All argument behaviors and constraints are fully documented, including the default case, date-only case, and date-range case. An output schema exists, so return-value details are not required. The tool is simple and the description covers all necessary usage context.

  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-description coverage is 0%, so the description carries the full burden. It explicitly defines each parameter, including the YYYYMMDD format and the dependency of end_date on date. This fully compensates for the absence of 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 a specific verb and resource: 'Get MLS match scores and status for a date or date range.' It further clarifies behavior based on arguments (no args, date only, date+end_date), which clearly distinguishes it from siblings like get_match_details 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 clear context for when to use each argument combination: no arguments returns the current matchweek, date returns a single day, and both date and end_date provide an inclusive range. It does not explicitly name alternative tools 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.

• 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 this as safe (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The description adds behavioral substance by explaining the calculation (average points-per-game of opponents faced) and the return structure (per-opponent breakdown). 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-sentence summary, followed by a clear explanation of the returned value and a usage hint. 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.

  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 fully covers the essential context: what it does, what it returns, and how to specify the team. The output schema handles any structural details beyond the description.

  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 schema provides only a field name 'team_id' with no description. The description compensates fully by explaining it is an 'ESPN numeric team ID' and giving a concrete example ('e.g. "18418" for Atlanta United FC'), which is essential for correct invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 team's strength of schedule based on opponents already faced.' It specifies the resource (team), the verb (get), and the exact metric (opponents' current points-per-game). This distinguishes it from sibling tools like get_team_schedule or get_adjusted_points_per_game.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents 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: 'Useful early in the season for "who has played the tougher schedule so far?" questions.' This implies when the tool is most appropriate, 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.

• get_teamA
  4.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds context about returns ('full team information including display name, abbreviation, and location') but does not disclose error behavior or rate limits. This is comparable to the reference example for a 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 short, front-loaded with the purpose, and contains no filler. The Args block clearly documents the parameter format and origin.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 an output schema and rich annotations, the description fully covers the necessary context: what it does, how to obtain the input, and what it returns. No gaps remain.

  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?

  While the schema only says 'Team Id', the description explains it is an ESPN numeric team ID, gives an example, and specifies that it comes from get_teams. This fully compensates for the 0% 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 and resource ('Get details for a specific MLS team'), and distinguishes itself from the sibling get_teams by emphasizing 'specific' and referencing the numeric ID. The return content is also previewed.

  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 states to use the numeric ID returned by get_teams, which both names the sibling tool and establishes a prerequisite. This makes the appropriate usage context clear.

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

• get_team_scheduleA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context by detailing the return fields (opponent, date, score if played, status) and the scope (current season, all matches). This goes beyond the annotations, though it stops short of describing pagination or possible edge cases like cancelations.

  Agents need to know what a tool does to the world before calling it. Descriptions 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, the second summarizes the response content, and the Args line gives parameter semantics. No sentence is wasted, 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?

  Given the tool's simplicity (one parameter, output schema present, clear annotations), the description is complete. It covers what the tool returns, which team it applies to, and how to specify the team. There is no notable gap for an agent to correctly select and invoke the tool.

  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 only provides 'team_id' as a required string with no description, leaving 0% schema coverage. The description compensates fully by explaining that it expects an ESPN numeric team ID and provides a concrete example ('18418' for Atlanta United FC). This gives the agent exact guidance for supplying 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 opens with a specific verb and resource: 'Get all matches for a single MLS team in the current season.' This clearly identifies both the action and the scope, differentiating it from siblings like get_match_details (single match) and get_scoreboard (general scoreboard). It also enumerates what is included (scheduled, in-progress, completed) 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 clearly states when to use the tool: when you need all matches for one MLS team in the current season. It does not explicitly mention alternatives or exclusions, but the context of sibling tools and the tool's name make the intended use obvious. A score of 5 would require explicit 'use this instead of X' guidance, which is absent.

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

• get_standingsA
  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, open world, and non-destructive. The description adds valuable behavioral detail beyond annotations: the response format (separate numbered tables per conference), ordering (points descending), and included stats (W/L/T, goals for/against, differential). This provides transparency about output structure 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, followed by a brief, useful elaboration on the response format. Every sentence adds value; 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 tool is simple with no parameters, and the description fully explains what the output will contain. It provides enough context for an agent to select this tool and understand the response, even without the output schema being shown.

  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%. The description doesn't need to explain parameters. Baseline for 0 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's function: 'Get the current MLS standings, grouped by conference.' It specifies the resource (MLS standings) and the organization (conference). It distinguishes from sibling tools like get_teams and get_scoreboard by focusing 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 Guidelines4/5

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

  The description implies usage context: use when you need current standings with conference breakdown. It doesn't explicitly name alternatives, but the context is clear enough given the sibling tools. A slightly higher score is not warranted because it doesn't say 'use instead of X'.

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

• get_teamsA
  4.7/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, covering safety. Description adds 'active' and return fields (numbered list with ID, name, abbreviation, city), which is useful context beyond the structured metadata. It doesn't mention ordering or pagination, but the output schema covers return 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?

  Three sentences, each earning its place: purpose, returned fields, and follow-up usage. Front-loaded with the primary action and immediately 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?

  For a zero-parameter list endpoint with a rich output schema and strong annotations, the description provides purpose, output contents, and a pointer to the relevant sibling. Nothing important 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 schema coverage is trivially 100%. Baseline for 0 params is 4; the description correctly omits 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 opens with 'Get all active MLS teams' – a specific verb, resource, and scope. It distinguishes from sibling get_team by noting that detailed specific-team information is available via get_team. Clearly states what output includes (ID, name, abbreviation, city).

  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?

  States the use case: retrieving all active teams. Explicitly directs the agent to use get_team with the ID or abbreviation for detailed information, providing a clear alternative for a common follow-up. No exclusions needed for a zero-parameter list tool.

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