Server Quality Checklist

Tool Scores

• faceit_get_match_historyA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It implicitly indicates a read operation and describes the return shape, but omits details like pagination behavior, rate limits, or error conditions.

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

  Conciseness5/5

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

  A single, well-structured sentence that front-loads the verb and resource. No filler or redundancy.

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

  Completeness4/5

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

  For a straightforward list tool, the description covers purpose and return type well. It lacks context on how to use pagination (though limit/offset are in schema) and how the tool relates to sibling tools, but these are not critical gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning over the schema's parameter descriptions, though it does reinforce what the returned list contains.

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

  Purpose5/5

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

  The description clearly states it gets a player's recent CS2 match history, with specific output elements (match ids, results, timestamps) and platform (FACEIT). This distinguishes it from siblings like get_player_stats or get_match_details.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives. It does not mention that match ids could be used with get_match_stats or get_match_details, nor any exclusions.

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

• faceit_get_match_detailsA
  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 of behavioral disclosure. It clearly indicates a read-only retrieval operation via 'Get' and lists what is returned, but it does not discuss potential errors, required permissions, or rate limits. For a simple read tool, this is adequate but not rich.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that immediately states the action and resource, then efficiently enumerates the returned content categories. Every word earns its place, with no redundancy or filler.

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

  Completeness4/5

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

  Despite lacking an output schema, the description lists the key information categories (teams, players, competition info, status, results), giving the agent a solid sense of what to expect. For a straightforward one-parameter tool, this is sufficiently complete, though it could benefit from noting any distinctive behaviors like optional filters or match state variations.

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

  Parameters3/5

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

  The input schema fully documents the only parameter (match_id) with a clear description, so the schema does the heavy lifting. The description adds no extra parameter-level detail, which is acceptable given 100% schema coverage. Baseline of 3 applies.

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

  Purpose5/5

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

  The description uses a specific verb ('Get') and resource ('general details for a specific FACEIT match'), clearly distinguishing it from siblings like faceit_get_match_stats by focusing on 'details' rather than 'stats'. It also enumerates key content (teams, players, competition info, status, results), making the tool's scope unambiguous.

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

  Usage Guidelines3/5

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

  The description implies when to use this tool—when you need general match details—but provides no explicit guidance on when not to use it or comparisons to alternatives like faceit_get_match_stats. The positioning as 'general details' offers some differentiation, but exclusions are absent.

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

• faceit_find_playerA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the need for an exact nickname and the output (player_id and basic profile info), but does not cover not-found behavior, error handling, or whether the operation is read-only. These gaps are notable for a tool expected to serve as a prerequisite for others.

  Agents need to know what a tool does to the world before 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, front-loaded with purpose and output, then usage guidance. Every word earns its place with no redundancy.

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

  Completeness4/5

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

  For a single-parameter lookup tool with no output schema, the description provides the essential information: what it does, when to use it, and what it returns. It is slightly incomplete regarding the exact shape of 'basic profile info' and error responses, but sufficient for an agent to invoke it correctly as a preliminary step.

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

  Parameters3/5

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

  Schema coverage is 100% with the nickname parameter described as 'Exact FACEIT nickname'. The description repeats 'exact nickname' in prose but adds no additional semantic value beyond the schema, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description explicitly states the tool looks up a FACEIT player by exact nickname to retrieve player_id and basic profile info. It also distinguishes from sibling tools by positioning this as the first step before other player_id-dependent tools.

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

  Usage Guidelines4/5

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

  The phrase 'Use this first before other tools that require a player_id' gives clear context on when to invoke this tool. However, it doesn't explicitly state when not to use it (e.g., if player_id is already known), lacking a full exclusion clause.

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

• faceit_get_player_statsA
  4/5.0
  Behavior3/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 the scope ('lifetime') and hints at the output ('K/D, ADR, win rate, headshot %, etc.'). However, it does not mention behavior on missing players, rate limits, authentication, or return format details beyond the stats list. This is adequate but leaves gaps for robustness.

  Agents need to know what a tool does to the world before calling it. Descriptions 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, front-loaded sentence that immediately states the action and scope. Every word earns its place: verb, resource, stats examples, and input. No filler or redundancy.

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

  Completeness4/5

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

  Given the tool's low complexity (2 params, no output schema), the description covers the essentials: what it does and the key input. It does not fully detail the return structure, but the listed stats (K/D, ADR, win rate, headshot %) provide a sufficient overview for an agent to know what to expect. A 4 reflects a small gap in output specification.

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

  Parameters3/5

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

  Schema description coverage is 100%, so parameters are already fully documented. The tool description adds no extra semantic value beyond restating 'player_id'. Per the baseline rule for high coverage, a score of 3 is appropriate; the description does not need to compensate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and 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 action ('Get'), the target resource ('a player's lifetime CS2 stats'), and the input ('using their player_id'). It distinguishes itself from sibling tools like match history/stats by focusing on lifetime player stats, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool (when lifetime CS2 stats are needed) and specifies the required input ('player_id'). It does not explicitly mention when not to use it or name alternatives, but the pointer in the parameter description to faceit_find_player implies a workflow. Given the absence of explicit alternatives in the description itself, a 4 is appropriate.

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

• faceit_get_match_statsA
  4.2/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the burden of behavioral disclosure. It lists included stats (kills, ADR, KAST, headshots, rounds) but does not mention error handling, rate limits, or confirmation that it is read-only. The verb 'Get' implies a safe read, but more detail could be expected.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 purpose and followed by a practical usage hint. Every word earns its place with no fluff or repetition.

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

  Completeness4/5

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

  For a simple one-parameter read-only tool with no output schema, the description is mostly complete: it states what the tool returns (stats) and where to get the input. It could be slightly more complete by mentioning failure cases or whether all rounds are included, but overall it adequately covers the essentials.

  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 description for match_id is minimal ('FACEIT match_id'), and coverage is 100%. The tool description adds meaningful value by specifying the source of the match_id ('Use a match_id from faceit_get_match_history'), which directly aids the agent in populating the parameter correctly.

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

  Purpose5/5

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

  The description uses a specific verb ('Get') with a clear resource ('detailed per-round, per-player stats for a specific FACEIT match') and scope. It distinguishes from sibling tools like faceit_get_match_details by emphasizing the granular per-round/per-player nature.

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

  Usage Guidelines4/5

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

  The description gives clear contextual guidance by telling the agent to use a match_id from faceit_get_match_history, which is a useful prerequisite. However, it does not explicitly state when not to use this tool or name alternative sibling tools for exclusion.

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