Server Quality Checklist

Tool Scores

• get_player_summaryA
  3.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, and the description does not contradict them. It adds valuable behavior beyond annotations: private profiles return limited fields, and the currently playing game is only returned 'if public'. It also states the API key requirement, which is an authorization detail not present in 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 tightly written: a one-line purpose statement, followed by a compact list of returned fields, then privacy and authorization notes. No redundant or filler words. The main function is front-loaded, making it quick to parse.

  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 read-only tool with an output schema present, the description is sufficient. It covers what the tool returns, privacy behavior, and authorization. The only missing piece is guidance on when to choose it over siblings, but that is already penalized under usage_guidelines.

  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 schema description covers 100% of the parameter, and it is exhaustive: steam_id accepts multiple formats (SteamID64, STEAM_1, URL, vanity name). The tool description does not add any extra meaning beyond the schema, so the baseline 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 verb 'Fetch' and the resource 'player's public profile summary', and lists specific fields returned (persona name, online state, etc.). It is distinct from sibling tools in intent, but does not explicitly differentiate itself from them by name or contrasting scope, so it does not earn a 5.

  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 versus alternatives. It mentions that an API key is required, but gives no context, exclusions, or comparisons with sibling tools like get_steam_level or get_player_bans. An agent would have to infer usage from the name alone.

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

• get_recently_played_gamesA
  3.7/5.0
  Behavior4/5

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

  With annotations already covering readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description's job is lighter. It adds valuable context beyond the annotations by disclosing the API-key requirement and the privacy prerequisite on the profile. These are genuine additions—none are captured in the structured data. Cannot reach 5 because it omits other behavioral traits like rate limits or timezone semantics, but this is strong 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.

  Conciseness4/5

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

  Three sentences, each earning its place: the purpose, the return shape, and the access prerequisite. The structure is front-loaded and scannable. It loses a point only because the final two sentences are terse fragments that could potentially be combined, but they are each independently informative and do not waste 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?

  For a tool with comprehensive annotations, a fully documented two-parameter schema, and an output schema, the description covers the essentials: scope, return content, and prerequisites. Minor gaps exist (e.g., no mention of pagination interplay between count and the two-week window, or timezone handling), but none are blocking for a correctly formed call.

  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%—both steam_id (with rich format examples) and count (bounds and default) are thoroughly documented in the input schema. The description adds no semantic meaning about the parameters beyond what the schema already provides. Per the rubric, when schema coverage is high, the baseline is 3, which the description exactly meets.

  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 'List games a player has played in the last two weeks' pairs a specific verb with a clear resource, and the return format is stated ('2-week and lifetime playtime'). It implicitly differentiates from siblings like get_owned_games by time-scoping the query. However, unlike the calibration 5 example, it does not explicitly name any sibling alternative to disambiguate selection.

  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 gives useful contextual constraints—'The profile must be public' and 'Requires an API key'—which inform when the tool can be used. However, it offers no explicit when-to-use comparison against siblings (e.g., when to prefer this over get_owned_games), nor does it list exclusions. It satisfies the 'clear context' bar but stops short of explicit alternatives, so a 3 is appropriate.

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

• get_steam_levelA
  3.9/5.0
  Behavior4/5

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

  Annotations already mark the tool as read-only, open-world, idempotent, and non-destructive, so the description does not need to restate those. It adds the useful behavioral note that an API key is required, which is beyond the structured annotations and schema. It does not detail rate limits or error behavior, but the annotations lower the bar.

  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 every word earns its place. The primary purpose is stated first, followed by a necessary prerequisite. No fluff or redundant restatement 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?

  For a single-parameter read-only tool with a complete parameter schema and an output schema, this description is sufficiently complete. The API key note is a useful extra context, and the agent has everything needed 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 schema already covers the single parameter completely, including accepted formats and examples. The description adds no extra parameter-level detail because it is unnecessary. With 100% schema coverage, a baseline 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 identifies the specific verb ('Get'), the resource ('a player's Steam community level'), and includes a necessary prerequisite. It is unambiguous, though it does not explicitly distinguish itself from sibling tools like get_player_summary, which might also surface user data.

  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 verb 'Get' implies that this tool is used when a caller needs a player's Steam level, providing a baseline sense of when to invoke it. However, it gives no explicit guidance about when not to use it, no alternative mention, and no context about how the API key should be supplied.

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

• get_app_reviewsA
  4/5.0
  Behavior4/5

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

  Behavioral transparency is well-covered by the annotations (readOnlyHint, idempotentHint, destructiveHint). The description adds 'No API key required' and outlines the output (summary and sample). This supplements the annotations without contradicting them, though it does not go into side effects (which are already indicated as none by the read-only hint).

  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 exceptionally concise, consisting of exactly two sentences. It avoids unnecessary details or fluff while conveying the core functionality. The structure is straightforward: first sentence states the purpose, second sentence details the return content. 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 tool has an output schema, so the description does not need to fully specify the return structure. However, it does mention key output elements (overall review label, positive/total counts, sample of recent reviews) which gives adequate context. Combined with the annotations and schema, the description is complete for an agent to invoke 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 already provides thorough descriptions for all three parameters (appid, limit, review_type), with examples and guidance. The tool description itself does not add extra meaning beyond this, but it does mention the output format, which indirectly clarifies the role of limit and review_type. Overall, schema coverage is 100%, so the description's additional value is minimal.

  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 a specific action: 'Summarize store reviews for a game and show a sample of recent ones.' It names the resource (store reviews) and the verb (summarize/show). This distinguishes it from sibling tools like get_app_details or get_news_for_app, which focus on other aspects.

  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 does not explicitly state when to use this tool versus siblings. It does mention 'No API key required', which is a usage note, but it lacks guidance on when to prefer this over get_app_details or get_news_for_app. The context is implicit from the tool's name and description, but not explicit.

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

• get_player_bansA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well-covered. The description adds useful context by specifying the ban categories and the API key requirement, but it does not describe error behavior, rate limits, or how ban results are structured; the output schema covers the 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?

  Two short sentences deliver the core purpose, the practical use case, and a critical prerequisite (API key). There is no filler or repetition of schema information, so 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 single-parameter, read-only tool with a rich input schema, strong safety annotations, and an output schema, the description provides all necessary selection context: what it checks, when it is useful, and what authentication is required. Nothing essential is missing.

  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 schema provides 100% coverage for the single parameter, including multiple formats, examples, and a thorough description of accepted Steam ID forms. The tool description adds no parameter-level detail, so it does not need to compensate for schema gaps.

  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 ('Check') and a precise resource (a player's VAC, game, economy, and community ban status), which clearly distinguishes it from sibling tools like get_player_summary or get_steam_level. It states exactly what information the tool retrieves.

  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 ('Useful for trust/reputation questions') that helps an agent decide when to invoke it. It does not explicitly name sibling alternatives or state when not to use it, but the use-case guidance is sufficient for most selection scenarios.

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

• get_friend_listA
  4.2/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 knows this is a safe read operation. The description adds useful behavioral context: the friend list must be public (implying potential failure if private), names are resolved in one batch call (efficiency), and an API key is required. 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. It front-loads the core purpose in the first sentence, then adds key constraints (public list, batch resolution, API key) in subsequent short sentences. Every sentence 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's simplicity (2 params, 1 required, no nested objects) and the presence of an output schema, the description is fairly complete. It covers the main behavioral aspects (public requirement, batch resolution, API key). It could mention what happens if the friend list is private or if the API key is invalid, but these are edge cases that the output schema or error handling might cover. The description is adequate for an agent to call 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?

  Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal extra meaning beyond the schema: it mentions 'with names' implying the limit parameter controls how many friends get names enriched, but this is already implied in the schema's description for limit. The description does not add significant new semantics beyond what the schema provides.

  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 purpose: 'List a player's friends, newest-friended first, with names.' It specifies the verb (list), the resource (a player's friends), and the ordering (newest-friended first). This distinguishes it from sibling tools like get_player_summary or get_owned_games, which serve different purposes.

  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: 'The friend list must be public.' It also notes the requirement of an API key. However, it does not explicitly mention alternatives or when not to use this tool, but the context is sufficient for an agent to understand the primary use case.

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

• resolve_vanity_urlA
  4.2/5.0
  Behavior4/5

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

  Annotations already cover readOnly/idempotent/destructive hintsщие, so the description's bar is lower. It adds the API key requirement and the return format ('all common formats, or not-found'), which are useful beyond annotations. No contradiction.

  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 plus one use-case sentence. Front-loaded purpose in line 1, immediate usage context, and expected return behavior. 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 output schema (not shown in full but flagged as present) would document return details, and the description already states the ID formats and not-found case. API key requirement is noted. Rate limits or failure modes are missing, but for a simple idempotent one‑parameter lookup this is sufficient.

  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 already describes the vanity parameter with a description and examples; description adds an extra example (gabelogannewell) and clarifies the input format by referencing the URL pattern. With 100% schema coverage, this baseline is adequate but not extensive.

  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 states a specific verb+resource: resolve a Steam custom URL name to SteamID64. It clearly distinguishes from sibling tools that operate on already-resolved SteamIDs (e.g., get_player_summary, get_owned_games), so an agent knows when to choose this tool.

  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 states the trigger condition ('when you only have a person's custom URL name and need the numeric id that other tools consume') and notes the API key requirement. No explicit exclusions or alternative tool names, but the purpose statement already implies when not to use it (when you have the numeric ID).

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

• get_current_player_countA
  4.3/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 openWorldHint=true. The description adds valuable contextual details beyond annotations: 'No API key required' (auth expectations) and 'Returns the live concurrent player count' (response nature). This exceeds what the annotations alone communicate.

  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 total, front-loaded with the core purpose, followed by use case, auth note, and lookup hint. No filler or redundant details; 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 single-parameter, read-only tool with an output schema and safety annotations, the description is complete: it states purpose, use case, auth requirements, and how to obtain the required appid. No invocation-critical information is missing.

  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 schema fully describes the single appid parameter with examples and the search_store guidance, so schema coverage is 100%. The description repeats the same search_store hint and provides the query framing, adding little new parameter meaning beyond what the schema already includes.

  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 action and resource: 'Get the number of players currently in a game' with 'live concurrent player count for an app'. This distinguishes it from sibling player-data tools like get_player_summary or get_player_achievements, which do not report live concurrent activity.

  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 identifies the use case: 'Great for "how many people are playing X right now?"' and points to search_store for finding the appid. It doesn't name alternatives or say when not to use it, but no sibling directly overlaps live player counts, so clear context suffices.

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

• get_game_schemaA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds useful context beyond annotations, including the API key requirement and the specific returned data shape. No contradictions 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 compact and front-loaded: the first sentence states the core purpose, the second details the return contents, and the third gives usage timing and an auth note. Every sentence earns its place with no 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 a rich output schema, full annotations, and a single fully-documented parameter, the description is complete. It tells the agent when to use the tool, what it returns, and the auth requirement. Nothing essential for invoking this tool correctly is missing.

  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 schema already fully documents the single parameter 'appid' with a helpful description, examples, and guidance to use search_store for discovery. The tool description does not add parameter semantics beyond the schema, so 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 uses a specific verb and resource: 'Get a game's achievement and stat definitions' and clarifies exactly what is returned: display name, achievement count/names, and tracked stats. This clearly distinguishes it from siblings like get_player_achievements or get_global_achievement_percentages, which check progress or aggregates rather than definitions.

  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 usage context: 'Use this to learn what achievements exist before checking a player's progress.' It also notes the API key requirement. It does not explicitly name alternatives or exclusion criteria, but the intended workflow is clear enough for an agent to select it correctly.

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

• get_owned_gamesA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the profile's game details must be public, an API key is required, and the return includes both a ranked table and library-wide totals. This is meaningful supplementary detail that helps an agent anticipate failures and response shape.

  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, information-dense sentences with no filler. The main purpose is front-loaded, followed by key requirements and practical usage tips. 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?

  Given the output schema exists and annotations cover read-only safety, the description is largely complete. It covers prerequisites (public profile, API key), output characteristics (ranked table, totals), and parameter usage. It could mention edge cases like invalid steam_id or empty libraries, but that is not essential 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 100%, so the baseline is 3. The description adds extra meaning by linking sort='recent' to the user intent 'what have they been playing lately?' and by noting limit controls response size. It also ties playtime ordering back to the 'total playtime per game' concept, adding practical 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 first sentence states the specific action and resource: 'List the games a player owns, with total playtime per game.' It also adds concrete output expectations (ranked table, library-wide totals), making the tool's purpose unmistakable and distinguishable from sibling tools like 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?

  The description gives clear context for when to use the tool (listing owned games with playtime) and offers concrete guidance for parameter usage: use sort='recent' for 'what have they been playing lately?' and limit to control response size. It doesn't explicitly discuss when not to use it or name alternatives, but the guidance is sufficient for an agent.

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

• get_app_detailsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value beyond annotations by stating 'No API key required', which is a key operational detail not in annotations or schema. It also lists what data is returned (review recommendation count, Metacritic score), giving a fuller picture of the tool's output. Since annotations cover most of the behavioral profile, the extra detail justifies a 4 in the context of full coverage.

  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: the first states the resource and return fields, the second covers prerequisites and authentication. It is front-loaded with the core purpose and field list, then addresses usage guidance. Every sentence earns its place; there's no fluff or 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 the tool has only 1 parameter, full schema coverage, and a rich annotation set (read-only, idempotent), the description is sufficient for correct invocation. It covers what it returns, prerequisites (appid discovery), and authentication needs. The technical note 'No API key required' is a critical completeness piece for a tool that often requires keys in similar APIs. Nothing essential is missing for an agent to call 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?

  Schema coverage is 100% and the parameter (appid) already has a clear description with examples. The description doesn't need to add much, but the tool description does mention the first step of the workflow ('Use search_store first') which is relevant to the parameter's usage (finding the appid). The schema's description of appid is thorough, so the definition adds marginal value beyond it, but the baseline is high due to coverage, making a 4 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 what the tool does: 'Get full store details for a game/app by appid.' It enumerates the returned fields (type, description, developers/publishers, price, etc.), which distinguishes it from siblings like search_store (which finds appids) or get_global_achievement_percentages (which gets achievements). This is specific and immediately actionable.

  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 explicit guidance: 'Use search_store first if you only have a name.' This directly tells the agent when to use this tool vs. its sibling, which is strong. The input schema also reiterates this with 'Use search_store to find an appid from a game name.' However, it doesn't detail alternative scenarios or non-usage cases, so a 4 is appropriate rather than 5.

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

• get_news_for_appA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnly, openWorld, idempotent, non-destructive. The description adds an authentication note ('No API key required') and specifies the returned fields (title, source feed, date, excerpt, link), enriching 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?

  Three sentences, each earning its place: purpose, output summary, and a cross-tool usage hint. Front-loaded with the core action.

  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 a simple two-param schema, full annotation safety profile, and existing output schema, the description covers the use case adequately. It even adds auth context and a discovery path for the required appid.

  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%, and the appid param description already includes the search_store suggestion and examples. The description repeats that hint but adds no new parameter-level semantics beyond the schema, so a baseline 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?

  States a specific verb+resource: 'Get the latest news / patch notes for a game.' It distinguishes from sibling tools like get_app_details and get_app_reviews by focusing on news, and the name itself reinforces it.

  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?

  Explicitly directs the user to search_store when only a game name is known, and notes no API key is required, setting expectations for invocation. It clearly positions the tool for news retrieval relative to other game info tools.

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

• search_storeA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds value by stating 'No API key required' and clarifying the return behavior ('matching apps with appids'). It does not contradict annotations, and while it doesn't mention pagination or error cases, the added context goes beyond structured fields.

  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 tight sentences plus a short paragraph. The core action is front-loaded, and the usage context is separated clearly. No filler or redundant phrasing; 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?

  Given the tool has an output schema (likely describing the result structure), full parameter documentation in the schema, and safety annotations, the description is complete enough. It covers purpose, usage context, the downstream tools it feeds, and authentication requirements. Nothing essential for correct invocation is missing.

  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% (both 'term' and 'limit' are described in the schema). The description adds no extra parameter-specific meaning beyond reinforcing that 'term' is the game name. Baseline 3 is appropriate because the schema already carries the full semantic load.

  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 states a specific verb ('Search'), resource ('Steam store'), and outcome ('return matching apps with appids'). It also distinguishes itself from siblings by explicitly noting it is the entry point that produces appids consumed by get_app_details, get_app_reviews, and stats tools, making its role clear.

  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 this is the entry point for most store workflows and specifies when to use it: when you need to turn a game name mentioned by the user into an appid. It also implicitly guides against using it when you already have an appid (go downstream directly) and notes that no API key is required, which is a practical usage constraint.

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

• get_global_achievement_percentagesA
  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 as true/false. The description adds no side-effect info but is consistent with a read-only query. Mentioning it returns a sorted list adds mild 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 concise (two sentences) and includes the essential purpose and a usage example. No redundant 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?

  The tool is self-contained: it has a clear input, describes the output (sorted achievements), and includes enough context for an agent to know when to call it. No missing critical details.

  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 single parameter appid is fully described with an example (440 for Team Fortress 2) and a hint to use search_store to find appids. No ambiguity.

  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 global achievement percentages for a game, sorted from rarest to most common. It distinguishes itself from per-player achievement tools like get_player_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?

  Mentions 'No API key required' and provides a typical use case ('what's the rarest achievement in X?'). It could explicitly contrast with per-player achievements, but the phrase 'across all players' implicitly conveys the scope.

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

• get_player_achievementsA
  4.6/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 knows this is a safe read operation. The description adds meaningful context beyond these: it requires a public profile and game ownership, and it requires an API key. This is valuable behavioral context that annotations don't capture. It could go to 5 if it mentioned rate limits or specific failure modes for non-public/non-owned profiles, but what's here adds value 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?

  Three sentences with zero waste. The primary purpose is front-loaded, the return format is summarized next, and the prerequisites are last. Every sentence earns its place 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 that an output schema exists (the tool has has_output_schema: true), the description needn't detail return values in depth, and its summary of the return shape (completion + list with dates) complements the output schema. The tool is moderately complex (profile ownership, public visibility, API key) and the description covers these prerequisites. Slight gap: it could mention what happens if the profile is private or doesn't own the game, but for the typical agent flow this description is adequate.

  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 100%, so the schema already documents both parameters well, including examples for both appid and steam_id. The description adds value by mentioning the return shape (overall completion and list of unlocked achievements), which helps the agent understand what the parameters do together. It doesn't explain format details of steam_id beyond schema examples, but schema coverage is high enough that the description doesn't need to repeat it. Being slightly above baseline 3 because it clarifies the purpose of the combination.

  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 as showing a player's achievement progress in one game, specifying the resource (achievements), the action (show progress), and the scope (one game). It distinguishes itself from siblings like get_global_achievement_percentages (which is global, not per-player) and get_game_schema (which lists achievements but not player progress).

  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 states when to use this tool: to see a player's achievement progress for a specific game. It also implicitly excludes when not to use it (e.g., for global percentages, use get_global_achievement_percentages; for schema, use get_game_schema). The prerequisites for use (profile must be public, must own the game) are clearly stated, helping the agent decide when this tool is applicable.

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