Server Quality Checklist

Tool Scores

• league_standingsA
  3.5/5.0
  Behavior3/5

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

  Without annotations, the description carries the burden and does disclose useful behavior: standings are final for completed seasons and current for ongoing ones, and are split by conference. It does not address edge cases like unavailable seasons or what happens when no standings 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?

  Two short sentences, each earning its place: the first states the tool's function and scoping, the second the required parameter format.

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

  Completeness4/5

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

  With an output schema available and only one parameter clearly described, the definition is adequate for a simple read-only standings lookup, though a brief pointer to alternative tools would have strengthened it.

  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 0%, so the description compensates by documenting the exact format for season ('YYYY-YY') with a concrete example, which is sufficient for the only parameter.

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

  Purpose4/5

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

  The description identifies the resource (standings) and scope (season, conference split), which distinguishes it from sibling tools like team_roster or stat_leaders, though the verb 'returns' is implied rather than explicit.

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

  Usage Guidelines2/5

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

  No guidance on when to choose league_standings over siblings such as stat_leaders or find_team; the season format is the only usage detail, and no exclusions or alternatives are mentioned.

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

• scoreboardA
  3.7/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 of behavioral disclosure. It does disclose the default behavior (defaults to today) and the date format, but it does not describe the return structure, edge cases like future/empty dates, or timezone handling. For a low-complexity read tool this is acceptable but minimal.

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

  Conciseness5/5

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

  Two sentences, no filler: the first states the purpose and default, the second documents the parameter format. Every word earns its place and the most important information is front-loaded.

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

  Completeness4/5

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

  For a tool with one optional parameter and an output schema present, the description covers the essentials: what the tool returns at a high level, the default behavior, and the required date format. Minor gaps like timezone handling or behavior for invalid dates exist, but they are not critical for correct invocation.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate, and it does. It explicitly documents that game_date must be formatted as 'YYYY-MM-DD' and clarifies that omitting it defaults to today. This adds meaning beyond the schema, which only declares it as a string with an empty default.

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

  Purpose4/5

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

  The description states the resource ('games and scores') and the controlling parameter (a date, defaulting to today). It is clear and specific enough to distinguish it from sibling tools like find_player or list_teams, though it does not explicitly contrast with the closest sibling, game_boxscore, and uses a noun phrase rather than a strong verb.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool — to retrieve games and scores for a date, defaulting to today — but provides no explicit exclusions or comparisons to alternative tools. An agent can infer usage but is not told when not to use it or which sibling covers other cases (e.g., game_boxscore for a single game's details).

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

• stat_leadersA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It usefully discloses valid stat values, the season format, and the limit cap. However, it does not mention ordering (e.g., descending by the chosen stat), tie handling, or whether the results are per-game averages, though output schema may cover 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?

  The description is compact and front-loaded: the main purpose appears first, followed by concise parameter constraints. Every line earns its place with no redundant wording or restating of the tool name.

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

  Completeness4/5

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

  Given the output schema exists, the lack of return-value detail is acceptable. Parameter coverage is strong and the tool's core behavior is clear. The main gap is absence of sibling differentiation and behavioral details like sorting or tie-breaking, but overall the definition is sufficient for correct invocation.

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

  Parameters4/5

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

  The input schema has no property descriptions, so the description is essential. It explains the accepted stat enum, the exact season format, and that limit is capped at 50, covering all three parameters. It could be slightly clearer that limit means the number of top leaders returned, but the meaning is strongly implied.

  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 per-game statistical leaders for a season, which is a specific verb+resource. It also enumerates the supported stat categories, adding precision. It does not explicitly differentiate from sibling tools, but the function is distinct enough from player lookups, rosters, and box scores.

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

  Usage Guidelines3/5

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

  The intended use is implied: call this when you need per-game statistical leaders for a season. It gives useful input constraints like stat values, season format, and limit cap, but it does not explicitly say when to prefer this tool over alternatives or provide exclusion criteria.

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

• team_rosterA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description implies a read-only roster lookup but adds no details such as whether the roster is active only, includes historical players, or is sorted. The behavior is predictable enough for a simple retrieve tool, but the description carries little behavioral context.

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

  Conciseness5/5

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

  Three short sentences, no filler; the purpose is front-loaded and the parameter guidance follows directly. Every sentence earns its place.

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

  Completeness4/5

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

  For a simple two-parameter lookup with an output schema available, the description covers how to obtain and format both inputs and names its source tool. It does not add selection criteria versus sibling tools, but the low complexity and output schema reduce that burden.

  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 0%, so this description is the only source of parameter meaning. It compensates nicely by telling the agent to get team_id via find_team and to format season as 'YYYY-YY'. It doesn't provide a concrete example or valid season range, which keeps it from a 5.

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

  Purpose4/5

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

  The description clearly identifies the resource—a team's roster—and the scope—a given season. It uses a noun phrase rather than an explicit 'get/retrieve' verb and does not explicitly distinguish itself from siblings like player_career_stats, though the resource is evident.

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

  Usage Guidelines4/5

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

  It gives concrete call prerequisites: obtain team_id from find_team and encode season as 'YYYY-YY'. It does not explain when to prefer this tool over alternatives or when not to use it, so it stops short of full routing guidance.

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

• player_career_statsA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral disclosure burden and does it well by specifying the exact return shape: regular-season and playoff career averages plus a season-by-season regular-season breakdown. It does not discuss edge cases such as invalid player_id, but for a simple stats-retrieval tool this is a minor gap.

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

  Conciseness5/5

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

  The description is two concise sentences with no wasted words. It front-loads the tool's purpose and uses the second sentence to add both the id source and the returned data structure.

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

  Completeness5/5

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

  For a tool with a single required parameter and an output schema present, the description provides sufficient context: what data is returned, what categories are included, and where the required id comes from. No critical information for calling the tool correctly 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 schema provides only minimal information for player_id as an integer, and schema description coverage is 0%. The description compensates by explaining that player_id should be obtained from find_player, which adds real semantic meaning beyond the schema.

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

  Purpose4/5

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

  The description clearly identifies the tool as returning career and per-season statistics for a player, including both regular-season and playoff career averages. It does not explicitly name a sibling tool to differentiate from, but the player-specific scope is clear and distinct from the other listed tools.

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

  Usage Guidelines3/5

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

  The description provides a valuable prerequisite by telling the agent to get player_id from find_player. However, it does not state when this tool should be chosen over stat_leaders, game_boxscore, or other siblings, leaving some selection logic to inference.

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

• game_boxscoreA
  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 carries the burden of explaining behavior. It does so by specifying the output content: final score and top 5 scorers per side. It also reveals the dependency on game_id from scoreboard, which is useful behavioral context, though it does not mention error cases or edge behavior.

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

  Conciseness5/5

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

  The description is extremely concise: one sentence defines the resource and output, and one sentence gives the prerequisite. Every word adds value and the key information is front-loaded.

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

  Completeness4/5

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

  For a simple single-parameter tool with an output schema, the description is nearly complete: it explains the purpose and the source of the required parameter. It could be slightly richer about how the result is scoped (e.g., current season only) but that is not essential given the surrounding context.

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

  Parameters4/5

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

  The schema provides only a game_id string with no description, so the description's instruction to get game_id from scoreboard adds real semantic value. It tells the agent where to find a valid value, which is sufficient for a single simple parameter, though it does not define the identifier format.

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

  Purpose4/5

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

  The description clearly identifies the tool as supplying a box score summary for a specific game, including final score and top 5 scorers per side. This distinguishes it from sibling tools such as scoreboard and player_career_stats, though it lacks an explicit verb like 'returns'.

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

  Usage Guidelines4/5

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

  'Get game_id from scoreboard' gives a clear prerequisite and tells the agent which sibling tool produces the needed input. It does not explicitly say when not to use this tool or name alternatives, but the context is obvious: use it after selecting a game from the scoreboard.

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

• find_teamA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It explains the accepted identifier forms and the return value, but says nothing about ambiguity on non-unique names, case sensitivity, not-found behavior, or whether the match must be exact. This is adequate for a simple lookup but leaves meaningful edge cases unstated.

  Agents need to know what a tool does to the world before 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, front-loaded with the action and ending with the downstream purpose. No redundant wording or generic filler.

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

  Completeness4/5

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

  For a one-parameter lookup tool with an output schema available, the description covers what identifiers to pass and why the result is useful. The only notable omission is behavior on no match or ambiguous match, which is minor given the tool's simplicity.

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

  Parameters4/5

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

  Schema coverage is 0% and the bare schema only says name is a required string. The description supplies the missing semantics by stating that name can be a team name, city, or 3-letter abbreviation, with BOS as an example. It doesn't cover input formatting or validation edge cases, but it makes the parameter's intended values clear.

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

  Purpose5/5

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

  The description opens with a specific action ('Look up an NBA team') and names three accepted identifier types, which is enough to distinguish this from find_player and list_teams. It also states the concrete deliverable, the team_id used by team_roster.

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

  Usage Guidelines4/5

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

  It gives clear context: use this when you need to resolve a team reference to the team_id consumed by team_roster. It doesn't name alternatives or exclusions, so it stops short of full 5.

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

• list_teamsA
  4.3/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 discloses a read-only list operation, exact cardinality ('all 30'), and the returned fields. It does not discuss auth or side effects, but none are implied for a simple list.

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

  Conciseness5/5

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

  A single sentence with no wasted words. The verb and scope are front-loaded, and every element adds useful information.

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

  Completeness5/5

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

  With zero parameters and an output schema present, the description is fully sufficient for an agent to invoke this tool correctly. Nothing an agent needs to know 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?

  There are zero parameters, and schema description coverage is 100%. The baseline for a no-parameter tool is 4; there is no parameter behavior to describe.

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

  Purpose5/5

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

  States a specific verb ('List'), resource ('all 30 NBA teams'), and output fields ('ids and abbreviations'). Clearly distinguishes from sibling find_team, which searches for a single team.

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

  Usage Guidelines3/5

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

  The description implies use when enumerating all teams, but it does not explicitly mention when to use find_team instead or any exclusions. Usage context is clear but alternative routing is left to inference.

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

• find_playerA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden and does well: 'Look up' signals a read-only operation, and it explicitly discloses that full or partial names are accepted and that the response includes the player_id plus any other name matches. It does not discuss case sensitivity or empty-result behavior, but these are minor for a simple lookup 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 two compact sentences with the main purpose front-loaded and the return usage immediately after. Every sentence adds information: matching semantics and downstream use.

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

  Completeness4/5

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

  For a one-parameter lookup tool with an output schema present, the description is nearly complete: it states the input semantics, the key output (player_id), and the relationship to player_career_stats. It does not explicitly mention how to handle multiple matches or no matches, but those are minor given the output schema and simple scope.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate for the bare 'name' parameter. It does so by explaining that the name is an NBA player name and that full or partial values are accepted. It stops short of format constraints such as case sensitivity or minimum length, but the core semantics are clear.

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

  Purpose5/5

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

  The description opens with a specific action and resource: 'Look up an NBA player by full or partial name.' It also distinguishes the tool from siblings by noting it returns 'the player_id needed by player_career_stats,' so an agent can tell it apart from find_team and the stats tools without opening schemas.

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

  Usage Guidelines4/5

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

  The description makes clear this is the tool for resolving an NBA player name into a player_id and explicitly points to player_career_stats as the downstream consumer. It does not state exclusions or name find_team as the alternative for team lookups, but the routing context is clear enough for typical use.

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