Server Quality Checklist

Tool Scores

• get_fixturesC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It mentions the probabilities are model-based and not betting advice, but does not describe what the output looks like (e.g., list structure, fields, ordering, any potential anomalies).

  Agents need to know what a tool does to the world before calling it. Descriptions 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, front-loaded with the core purpose. The disclaimer about not being betting advice is brief and adds clarity without unnecessary verbosity.

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

  Completeness2/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 should compensate by explaining the return value. It does not specify what fields are returned (e.g., team names, match times, probability values) or the shape of the response. This is a significant gap for an agent aiming 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 provides a complete description of the single parameter, including examples and a pointer to list_leagues. The tool description adds no additional parameter meaning, but 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.

  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 upcoming matches for a league, including model-based probabilities for specific betting markets. It distinguishes from siblings like get_results (past matches) and get_match (single match) by focusing on upcoming fixtures with probabilities.

  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 such as get_results or get_league_table. The only usage hint is within the parameter description (use list_leagues to discover league keys), which is about parameter discovery, not tool selection.

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

• get_teamA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description must fully convey behavioral traits. It describes the output content in detail, but does not explicitly state that the tool is read-only, idempotent, or has no side effects. For a retrieval tool this is acceptable, but additional behavioral context (e.g., data freshness, any rate limits) would improve 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 single, well-structured sentence that front-loads the core purpose ('One team in a league season') and then enumerates the major output components. Every word earns its place; there is 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 the lack of an output schema, the description does a good job of summarizing the returned data (table row, match log, goal-timing bins, etc.). It covers the main aspects of the response. However, it does not describe the structure or format of the output, which would be helpful for parsing. Overall, it is fairly complete for a 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?

  All three parameters have thorough descriptions in the input schema, including examples and references to other tools (e.g., 'see get_league_table / list of teams' for team slug). The tool description adds no additional information about the parameters beyond what the schema provides, so it does not add value 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 the tool returns data for a single team in a league season, listing specific outputs: table row, full match log with details, goal-timing bins, first-goal distribution, and per-team stats. This distinguishes it from sibling tools like get_league_table (which returns all teams) or get_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 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 vs. alternatives. It does not mention scenarios where a different tool (e.g., get_league_table for a list, get_fixtures for upcoming matches) would be more appropriate. The sibling tools are listed in context but no usage differentiation is given.

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

• get_league_tableA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the full burden. It states the output includes 'last-5 form' which implies some computational aggregation, but does not disclose if the tool is read-only, caching behavior, or if it requires authentication. The description is adequate but lacks depth for a tool with no annotation safety net.

  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 sentence with key details front-loaded (standings, points, W/D/L, goals, goal difference, last-5 form). It is efficient and avoids fluff, though it could benefit from a slight structural break (e.g., separating what vs. how) for easier parsing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 (both well-documented in schema), no output schema, and no nested objects, the description covers the main output fields adequately. It omits mention of pagination or sorting order (implicitly by position), but for a simple standings tool 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 schema already documents both parameters thoroughly. The description adds no new parameter-level meaning beyond the schema; it only mentions 'league season' which maps to the season parameter. 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 returns 'Current standings for a league season' and specifies the exact fields included: position, points, W/D/L, goals, goal difference, last-5 form. This makes the verb (get) and resource (league table) very specific, and the listed fields differentiate it from siblings like get_rankings or get_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 for retrieving standings for a specific league and season, but does not explicitly state when to use it versus alternatives like get_rankings or get_results. There is no guidance on exclusions (e.g., when to use get_rankings for league-wide stats instead), nor prerequisites beyond the league key hint.

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

• get_resultsA
  3.7/5.0
  Behavior3/5

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

  No annotations exist, so the description must fully disclose behavior. It discloses ordering (oldest first) and the cap on most recent matches, but introduces potential confusion: 'oldest first' vs 'most recent' cap could lead to ambiguous interpretation. No mention of error handling, default values, or response type.

  Agents need to know what a tool does to the world before 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 sentences, no fluff, front-loaded with the core function. Every word earns its place.

  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?

  No output schema exists, so the description should compensate by fully describing the return structure. It lists key output fields (FT/HT scores, first-goal minute) but omits other likely information (team names, dates, league/season). Adequate for a list endpoint but leaves gaps about the exact object 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 description coverage is 100%—all four parameters have descriptions. The tool description adds no new parameter-specific semantics beyond what the schema already provides; it only loosely contextualizes 'last' as a cap, which is redundant with the schema's 'most recent' phrasing.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 finished matches of a league season with FT/HT scores and first-goal minute, in oldest-first order. This verb+resource combination is distinct from siblings like get_fixtures (future matches) and get_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 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 compared to alternatives. Implied use is for finished matches only, and optional filters are described, but the description does not contrast with e.g. get_fixtures for pending matches or get_match for a specific match.

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

• get_goal_timingA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosing behavior. It reveals output content (goals per 15-minute bin, late-goal share) but does not clarify details such as how 'late' is defined, whether all seasons are aggregated, or if the data is read-only. It is adequate but leaves some behavioral unknowns.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 single, information-dense sentence that front-loads the core concept. It avoids redundancy and every clause adds value, 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 tool with two parameters, no output schema, and no annotations, the description gives a solid overview of the return value. It mentions both per-team and league-level outputs, but could be more explicit about the exact time bins and the definition of 'late' to be fully complete. Still, it covers 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 description coverage is 100%, so both parameters (league, season) are well documented in the schema. The description adds context about the output (per team, league-level) but does not introduce additional parameter meaning beyond what the schema already provides, 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 identifies the tool's function: it returns goals per 15-minute bin per team for a league, plus league-level stats. This is a specific verb+resource combination that distinguishes it from sibling tools like get_league_table or get_rankings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 what the tool does but does not explicitly state when to use it over alternatives or exclude cases. The user must infer from the unique output that this is for goal timing analysis, but no direct guidance or alternative naming is provided.

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

• get_track_recordA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It reveals that this is a read operation (track record), provides scoping (settled predictions only) and states data transparency (no cherry-picking). However, it does not mention whether the data is aggregated across all markets or if there are pagination/rate limits, leaving some behavioral aspects implicit.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 no wasted words. Every sentence adds value: the first states the purpose and scope, the second clarifies the data type and integrity. Information is front-loaded effectively.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 single-parameter tool with no output schema and no nested objects, the description is largely complete. It covers what the tool returns (prediction grades, hit rates, P/L) and the scoping constraint (settled predictions only). A minor gap is that it doesn't mention whether the date range is configurable beyond the days parameter, but the input schema handles this. Overall, it is sufficient for an agent to understand 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 adds context by stating the default lookback (90 days) implicitly via the 'default 90' mention in the schema, but does not add new meaning beyond what the schema already provides. The parameter is simple and well-documented 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 uses a specific verb ('get') and clearly identifies the resource ('public, settled prediction track record'). It distinguishes itself from siblings by explicitly stating what it covers (model signals graded against real results) and what it does not (no cherry-picking). The mention of 'FC' and specific data types (hit rates, P/L) adds further specificity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 reviewing model accuracy and performance, but it does not explicitly state when to use this tool versus alternatives like get_season_projection or get_rankings. No clear when-not-to-use guidance or alternative names are provided, leaving the agent to infer context 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.

• get_season_projectionA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the behavioral disclosure burden. It states the simulation count (10,000) and refresh frequency (daily), but does not mention data sources, processing time, or whether the results are cached. This is decent but could be richer for a computational 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 a single, information-dense sentence that front-loads the core concept (Monte Carlo season projection) and lists outputs concisely. Every part 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 tool has a single parameter with a well-described example, no output schema, and no nested objects, the description provides sufficient context about output content (probabilities, points, percentile range) for an agent to understand what to expect. It could mention typical result structure explicitly, but the current completeness level is high for a 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?

  Since schema description coverage is 100%, the baseline is 3. The description does not add parameter-specific details beyond what the schema provides, but the league parameter is well-documented inline. The tool has only one required parameter, so no additional 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 provides a Monte Carlo season projection with 10,000 simulations and daily refresh. It lists the specific outputs: title, top-4, relegation probabilities, mean final points, and percentile range, making the purpose highly specific and 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 gives clear context that the tool should be used for season projections based on Monte Carlo simulations. It does not explicitly exclude alternatives like get_league_table for current standings, but the statistical nature implies this is for forward-looking analysis, which is adequate guidance given the sibling tool context.

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

• list_leaguesA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description does a good job disclosing behavior: it is a read-only listing operation returning all available leagues. The note about ordering (newest first for seasons) adds helpful context. No contradictions since no 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.

  Conciseness5/5

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

  The description is two sentences and contains exactly what is needed: what data is returned, ordering, and usage guidance. 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 no parameters, no output schema, and no annotations, the description covers the essential behavioral and functional aspects well. It could optionally mention that no authentication details are needed for this listing, but it is already complete enough 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 schema has no parameters (0 params, 100% coverage by default), so the description does not need to compensate. It correctly implies no input is needed and focuses on explaining the output structure 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 states the tool lists over 90 leagues with specific fields (country, league key, seasons available). It distinguishes itself from sibling tools which are more specific to matches, teams, or 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 explicitly says to call this tool first to resolve league keys and season strings, implying it is a prerequisite for other tools. It does not directly name alternatives but the purpose naturally differentiates it.

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

• get_matchA
  4.2/5.0
  Behavior4/5

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

  Without annotations, the description fully discloses behavioral aspects: it returns probability models, team ratings, and histograms. It clarifies input requirements (slug format) and the model is read-only (get), which aligns with the tool's purpose. No contradictions with missing 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 a single, well-structured sentence that efficiently conveys purpose, input format, and output contents 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?

  The description is complete for a single-parameter tool with a simple return model. No output schema is needed given the detailed description of what is returned. A minor gap: it does not explain return format or potential error conditions, but for this context it 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?

  Schema coverage is 100% with one parameter. The description adds meaning by explaining the slug format and source (get_fixtures), but the schema already provides an example. This adds some value beyond the schema, justifying a 3 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 uses specific verbs and resources: 'get_match' retrieves a match by 'slug'. It details the return data (full probability block across markets, team ratings, histograms) and explains the slug format, distinguishing it from siblings like get_results or get_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 explains the required slug format (country/league-slug/date-home-vs-away) and references get_fixtures as the source for slugs, providing clear context for use. It does not explicitly state when not to use this tool or mention alternatives among siblings, but the specificity is strong.

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

• get_rankingsA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It clearly discloses the two ranking behaviors ('luck-adjusted over/under-performance' and 'highest-scoring matches'), which gives the agent a solid understanding of what the tool computes. It does not describe the shape of the returned data or any side effects (likely none), but for a read-only ranking tool this is sufficient. Loss of one point for no mention of data 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?

  Two concise sentences with no fluff. The first sentence states the core purpose, and the second provides essential detail on the two view options. Every word earns its place; no extraneous 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 that there is no output schema, the description could have noted the return format, but for a ranking tool with only two enum-based views, the description is complete enough. The parameter schema covers the required inputs thoroughly, including the hint to use list_leagues for valid keys. No missing pieces that would impair an agent's ability to select or 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?

  Schema coverage is 100% (all three parameters are described in the input schema). The description adds contextual meaning about the 'view' parameter (explaining what 'luck' and 'goals' mean), which goes beyond the schema's simple 'Ranking view'. For 'league' and 'season', the schema already provides adequate descriptions, including the cross-reference to 'list_leagues' for discovering valid keys. This is a balanced, helpful addition 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 specifies exactly what the tool does: it reranks a table based on alternative views ('luck' or 'goals'), with clear explanatory parentheticals for each view. This distinguishes it from the sibling 'get_league_table', which presumably returns the standard ranking, and names the two alternative sorting criteria unambiguously.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 an alternative ranking view is desired (luck-adjusted or by goal tally). It does not explicitly state when NOT to use it (e.g., if you need the standard league table, use 'get_league_table' instead), but the sibling tool names and context make this fairly clear. A direct exclusion reference would make this a 5.

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