Server Quality Checklist

Tool Scores

• steam_get_player_achievementsA
  4.2/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint, so basic safety is clear. The description adds value by detailing return formats (markdown/json), error handling ('Error: ...'), and a note for games with no achievements, which goes beyond annotation info.

  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 main sentence, an 'Args' section listing parameters, and a 'Returns' section. Every sentence provides useful information without redundancy.

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

  Completeness5/5

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

  Given that an output schema exists but the description explains the return structure (markdown/JSON with game name, counts, list), and the tool is simple and read-only, the description is complete and sufficient for an agent to understand behavior and output.

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

  Parameters5/5

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

  Despite schema description coverage being 0%, the tool description thoroughly explains each parameter: appid (required, what it is), steam_id (fallback to env var), only_unlocked (filter), response_format (output type). This adds meaning beyond the schema's property descriptions, especially the fallback behavior.

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

  Purpose5/5

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

  The description clearly states 'Get a player's achievements for a specific game,' which is a specific verb+resource. It is distinct from sibling tools like steam_get_owned_games or steam_get_player_summary, which focus on different data.

  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 does not provide guidance on when to use this tool versus alternatives. It lacks explicit context for when to choose it over siblings, and no when-not-to-use or prerequisite information is given.

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

• steam_get_player_summaryA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint, and the description adds value by noting that some fields are only returned if the profile is public and that the response can be markdown or JSON. It also mentions error handling with 'Error: ...' strings.

  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, with a clear purpose sentence followed by a list of returned fields and an Args section. Every sentence adds value, and there is no unnecessary 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?

  Given the tool's simplicity, the annotations, and the presence of an output schema (not shown but noted), the description covers all necessary aspects: what is returned, privacy caveats, parameter details, and error format. It is self-contained and sufficient for correct 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?

  The input schema already contains descriptions for both parameters (steam_id and response_format), so the description repeats this information without adding significant new meaning. With high schema coverage, the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool retrieves profile summary information for a Steam user, listing specific returned fields like display name, profile URL, and online status. This distinguishes it from siblings (owned games, achievements, etc.) by focusing solely on the user's profile summary.

  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 on when to use the tool, such as specifying the required steam_id with a fallback to an environment variable. It does not explicitly exclude alternatives but implies usage for profile lookup, which is adequate.

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

• steam_get_recently_played_gamesA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context such as the fallback to STEAM_ID env var and return of error strings. 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.

  Conciseness4/5

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

  The description is well-structured with clear sections for arguments and returns, though the Args block is slightly verbose. Overall, it's concise and front-loaded with the main purpose.

  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 simplicity, the description covers key aspects: input parameters, return format, and error handling. The presence of an output schema reduces the need to detail return values.

  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 description adds meaning beyond the input schema by explaining the steam_id fallback behavior and the default count. Schema descriptions already exist for other parameters, but the description organizes them usefully.

  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 'List games a Steam user has played in roughly the last two weeks,' providing a specific verb and resource. This distinguishes it from siblings like steam_get_owned_games (all owned) and steam_get_player_achievements (achievements).

  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 implicitly guides usage by specifying the scope (recently played games) and parameters, but does not explicitly mention when not to use or provide alternatives.

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

• steam_get_owned_gamesA
  4.4/5.0
  Behavior4/5

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

  Adds context about privacy requirement and fallback beyond annotations; no contradictions.

  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?

  Well-structured with summary, args, returns; could be slightly more concise but not wasteful.

  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?

  Covers return format, error handling, prerequisites, and fallback; complete for a read-only query 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 provides detailed descriptions; description summarizes with defaults and usage, adding slight value.

  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 the tool lists owned games with playtime, distinguishing it from siblings like steam_get_recently_played_games.

  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?

  Specifies prerequisite (public profile), fallback to environment variable, but does not contrast with alternative tools.

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

• steam_resolve_vanity_urlA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds details on return value format (success: SteamID64 + name; failure: error string; no match: message), which goes beyond annotations. No contradictions.

  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 with short paragraphs, front-loads the main purpose, and uses clear structure with Args and Returns sections. No unnecessary 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?

  Given the tool's simplicity, the description fully covers purpose, usage, parameter, and return value. Annotations and output schema handle the rest.

  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?

  Despite the context claiming 0% schema description coverage, the actual schema includes a description for the parameter. The tool description further explains the parameter's meaning and gives an example, adding value beyond 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 clearly states it resolves a vanity URL to a SteamID64, using specific verb 'Resolve' and resource 'vanity profile URL name'. It differentiates from sibling tools by noting that other tools need numeric ID, so this tool is the prerequisite.

  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?

  The description explicitly says to use this tool first when only having a custom URL name, implying alternatives are the sibling tools that require numeric ID. It also specifies what input is valid (only the name, not full URL).

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