Server Quality Checklist

Tool Scores

• get_my_libraryA
  3.8/5.0
  Behavior4/5

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

  Beyond the readOnlyHint and openWorldHint annotations, the description discloses two non-obvious behaviors: the API key requirement and the default sort order ('most-played first'). This adds meaningful operational context that an agent needs to avoid errors. It stops short of revealing error handling or rate-limit behavior, but for a read-only library query this is quite good.

  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 primary output (owned games with hours) and then the key prerequisite. Every clause earns its place—no filler or redundancy. The ordering detail is embedded naturally rather than appended as an afterthought.

  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 read-only query, the description covers the essential context: what the tool returns, the default sort, and a critical authentication requirement. It does not explain what happens without an API key or when the profile is private, but those failure modes are implicitly covered by 'requires.' The absence of an output schema is acceptable since none is provided, and the description provides enough to call the tool correctly in most cases.

  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% (all three parameters are described inline), so with a high coverage baseline of 3, this score is appropriate. The description's mention of 'most-played first' provides a default ordering hint that hints at the limit parameter's interaction but does not describe any specific parameter semantics beyond that. No contradictions or extra 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 states exactly what the tool returns: the player's owned games with hours played, in a specific order (most-played first). This clearly differentiates it from siblings like get_recently_played and get_wishlist, even without naming them. The verb 'get' appears in the tool name and the description's noun-phrase structure is unambiguous.

  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 mentions a prerequisite (Steam API key and public profile) but provides no guidance on when to use this tool over its siblings. It does not contrast with get_recently_played or get_wishlist, nor does it suggest alternatives for different intents. An agent is left to infer usage boundaries from the tool name alone.

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

• get_game_detailsA
  4/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, and the description adds meaningful context: 'Keyless' clarifies no authentication is needed, and 'optionally Steam Deck compatibility. Slower' discloses a performance trade-off. This goes beyond the structured 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 a single, front-loaded sentence that immediately states the tool's purpose, then lists the returned fields compactly. There is no filler 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 read-only detail tool with two well-documented parameters, the description covers the main return fields, the auth requirement, and the optional slower behavior. It does not describe response shape or error cases, but the absence of an output schema makes the field list reasonably 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 description coverage is 100%, so the schema already documents appids and include_deck_compat. The description mentions 'one or more games by appid' and the optional deck flag, but adds no extra semantic detail 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 states a specific verb and resource: 'Full detail for one or more games by appid', and enumerates the exact fields returned. It distinguishes itself from siblings like get_game_reviews and search_games by emphasizing full detail keyed by appid.

  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 usage: call this when you have Steam appids and need comprehensive game details. However, it does not explicitly contrast with alternatives or state when not to use it, leaving the routing decision partly to inference.

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

• get_recently_playedA
  4.2/5.0
  Behavior4/5

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

  The annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation that works across the open Steam world. The description adds that it requires a Steam API key, which is a behavioral constraint beyond the annotations. This is valuable context. There's no contradiction, and the description adds meaningful context about authentication requirements.

  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 core purpose and scope are front-loaded in the first sentence, followed by the contrast with a sibling and the API key requirement. Every sentence earns its place, and the structure is logical and readable.

  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 a 100%-covered schema and no output schema, the description is quite complete. It includes the typical use case, a distinguishing contrast, and the authentication prerequisite. The only minor omission is that it doesn't describe the return format, but that's typically expected from the tool's response and the description already covers the choice criteria and invocation requirements.

  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%, so the schema already documents the single parameter 'user' with its description. The description does not add additional semantics beyond the schema, but it's not required because coverage is complete. The baseline of 3 applies here; the description doesn't compensate further, but it doesn't need to.

  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: it retrieves recently played games in the last two weeks. It explicitly contrasts this with get_taste_profile, which describes lifetime habits, making the purpose unambiguous and differentiating it from a key sibling. The verb 'get' combined with the specific resource 'recently played' and the explicit timeframe provides a strong, specific purpose.

  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 you need current mood based on recent activity, versus lifetime habits from get_taste_profile. It explicitly names the alternative and the condition differentiating them. However, it does not explicitly state when not to use it or mention other alternatives like search_games or get_game_reviews, but the context given 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_taste_profileA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the description only needs to add context beyond that. It adds the Steam API key prerequisite and describes the analytical behavior and output categories. It does not cover failure modes like private libraries, but that 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?

  Two compact sentences, with the core purpose and outputs front-loaded, followed by practical use cases and the auth requirement. Every sentence earns its place with no 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 read-only, two-parameter tool with complete schema coverage, this description is nearly complete: it explains the return content, use cases, and authentication requirement. A minor caveat about needing a public Steam profile could be added, but 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?

  Schema description coverage is 100%, with both 'user' and 'depth' fully documented including defaults and constraints. The description adds no parameter-level 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.

  Purpose5/5

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

  States a specific action ('derive') with a clear resource ('what a player actually likes from their library') and enumerates the concrete outputs: tag affinities, top genres, signature games, and bounced titles. This clearly distinguishes the tool from raw library access or recommendation 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?

  Offers explicit use cases: 'explain or sanity-check a recommendation' and answer 'what kind of games am I into'. It gives clear context for when to use the tool, though it does not explicitly name sibling tools to avoid or state when not to use it.

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

• get_wishlistA
  4.3/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, and the description goes beyond them by adding the keyless-access condition for public profiles and clarifying the returned data includes price and review info. This adds meaningful behavioral context without contradicting 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?

  The description is a compact three-sentence definition, each sentence earning its place: what the tool returns, why it is useful, and a key access condition. It is front-loaded and free of filler.

  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 simple–two optional params, a read-only operation, and no nested objects or output schema required for invocation. The description provides the output shape and access context, making it effectively complete for agent selection and correct calling.

  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 the user and limit parameters already have clear descriptions and defaults. The tool description gives no additional parameter-level semantics, 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 states a specific verb and resource—'get' the player's Steam wishlist—and details the content: current price and review data for each entry. This distinguishes the tool from siblings like get_game_reviews and get_my_library, so an agent can identify it without inspecting 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?

  It provides concrete use context: a wishlist is a stated-intent signal and is useful for spotting items on sale, and it notes that no key is needed when the profile is public. It does not explicitly state when not to use it or name alternative tools, so some selection guidance is left to the agent.

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

• list_tagsA
  4.3/5.0
  Behavior3/5

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

  The annotations already provide readOnlyHint and openWorldHint, and the description does not contradict these. It adds the context of when to call, but it does not describe other behavioral aspects such as output format, error handling, or side effects. Given the annotations cover the read-only behavior, the description adds marginal value in this dimension.

  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. The first sentence states the core purpose, and the second provides usage guidance. It is front-loaded with the main action and avoids any superfluous content. The example is brief but illustrative, fitting naturally into the guidance.

  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 simple search tool, the description provides sufficient context: what it searches, when to use it, and an example of a potential pitfall. The annotations cover read-only and open-world aspects, and there is no output schema to explain. The description adequately addresses the likely questions an agent would have, making it complete for its complexity.

  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 full coverage of both parameters (limit and contains) with descriptions, types, and constraints. The tool description does not add any additional semantics beyond what the schema already states. Since schema coverage is 100%, the baseline score is 3, and there is no extra explanation to elevate it.

  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: searching Steam's official tag vocabulary. It also provides explicit guidance on when to use it (before recommend_games or search_games when unsure about a tag), which effectively distinguishes it from sibling tools. The verb 'search' and the resource 'Steam's official tag vocabulary' are specific and unambiguous.

  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 tells when to use this tool versus alternatives: 'Call this before recommend_games or search_games when you are unsure a tag exists or what it is called.' It even includes a concrete example ('roguelite' vs 'Rogue-lite') to illustrate the type of confusion, leaving no doubt about the intended usage.

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

• get_game_reviewsA
  4.4/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, so the safety profile is covered. The description adds value beyond that by noting 'Keyless' (no authentication) and specifying that it returns 'Score breakdown plus the text of the most helpful reviews,' giving insight into the selection mechanism. It does not contradict annotations and provides useful behavioral context such as the notion of 'helpful' reviews.

  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 long, front-loading the core functionality (score breakdown and reviews) and then adding a clear use case. Every clause earns its place; there is no fluff or repetition. It is concise and well-structured.

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

  Completeness4/5

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

  With only two parameters and no output schema, the description sufficiently explains the return content ('score breakdown plus the text of the most helpful reviews') and the purpose. It does not mention pagination or potential errors, but given the simplicity and the presence of a 'samples' parameter to control volume, the description is complete enough 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.

  Parameters3/5

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

  The input schema covers both parameters with descriptions (appid as 'Steam app id.' and samples as 'How many review texts to return. Default 6.'), achieving 100% schema description coverage. The description adds no additional parameter semantics beyond what the schema already provides, so a 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 states a specific verb and resource: 'get_game_reviews' returns a score breakdown and review texts for a single game. It clearly differentiates itself from tag-based tools by stating 'which tags alone cannot tell you,' and the phrase 'for one game' distinguishes it from broader tooling. This is precise and unambiguous.

  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 tells when to use the tool: 'Use this to judge whether a game actually delivers on a specific preference (pacing, difficulty, story, how well it runs).' It also contrasts with an alternative (tags), implicitly stating when tags are insufficient. Although it doesn't name sibling tools directly, the contrast with tags provides clear usage context and a condition for selection.

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

• search_gamesA
  4.4/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, and the description adds useful behavioral context: it is keyless, returns full details per hit, and performs no personalised ranking. These traits go beyond what annotations alone convey, though it does not discuss rate limits or pagination.

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

  Conciseness5/5

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

  Three short sentences with zero filler. The core action is front-loaded, the usage guidance follows immediately, and the keyless note is a single efficient word.

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

  Completeness4/5

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

  The description covers the tool's purpose, key differentiator, and auth requirement, which is strong for a search tool with rich schema documentation. Without an output schema, it only vaguely characterizes the return payload as 'full details', but this is a minor gap given the clear purpose.

  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 88%, so the schema already documents most parameters thoroughly. The description adds little about specific parameters beyond the general notion of 'structured filters', 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?

  States a specific verb ('Search the Steam store'), the mechanism ('structured filters'), and what is returned ('full details for each hit'). It explicitly distinguishes itself from recommend_games by noting the lack of personalised ranking, making sibling differentiation 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?

  Gives an explicit usage condition ('when you want raw discovery without any personalised ranking') and names the preferred alternative ('recommend_games is usually the better starting point'). This is direct guidance an agent can act on without requiring inference.

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

• find_similar_gamesA
  4.6/5.0
  Behavior5/5

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

  Goes well beyond the readOnlyHint and openWorldHint annotations by disclosing the internal algorithm: it takes dominant community tags, searches on them, and scores results by tag overlap. It also reveals keyless operation and personalization behavior when a key is available, which is valuable for an agent deciding whether to pass a user.

  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 tight sentences with zero filler. The first sentence establishes purpose with examples, and the second explains the mechanism and key behavior. 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 4-parameter read-only tool with well-documented schema and annotations, the description covers purpose, mechanism, scoring, keyless behavior, and personalization. It does not describe the return format or ordering explicitly, but that is largely inferable from the scoring explanation.

  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%, so the schema already documents all parameters. The description adds meaningful semantics for appids by explaining they are seed games whose dominant tags drive the search, and clarifies the personalization dimension behind user and exclude_owned. This exceeds the baseline without duplicating 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?

  States a specific verb ('Find games resembling') and resource ('one or more you name'), with concrete natural-language examples that make the intent unmistakable. The mechanism is also stated (tag-based search and overlap scoring), which distinguishes it from generic search or recommendation 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?

  Gives clear usage context: use it when you have seed games in mind and want similar titles, including multi-seed queries like 'something between Factorio and Rimworld'. It does not explicitly name alternatives or exclusion conditions, but the examples and tag-based approach make the intended use obvious.

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

• recommend_gamesA
  4.7/5.0
  Behavior5/5

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

  Annotations already provide readOnlyHint and openWorldHint, but the description goes far beyond them. It discloses the exclusion of owned/wishlisted games, the 0-100 match score and tag attribution, the intentional ordering for variety ('a lower score can sit above a higher one'), and the no-API-key fallback. These are nontrivial behavioral traits that an agent must know to interpret results correctly. No contradictions with annotations are present.

  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 yet information-dense, with no filler. It front-loads the purpose, then gives usage examples, defaults, return format, and a fallback behavior in a logical flow. Each sentence carries unique information, and the length is appropriate for the tool's complexity. The structure makes it easy for an agent to parse quickly.

  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 10-parameter schema (all documented) and no output schema, the description covers the essential missing pieces: what the output contains (candidates, score, tags, caveats), the ordering quirk, exclusion defaults, and the no-API-key fallback. It is complete for an agent to invoke the tool correctly and interpret results, even for a recommendation engine with this many options. No significant contextual gap remains.

  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%, so each parameter is already described. The description adds value by giving vivid examples for the required `preference` parameter and clarifying that `tags` are exact and can be pinned. It also confirms the default behavior for `include_owned` by mentioning exclusion by default. While it doesn't delve into every parameter, the combination of complete schema and these clarifications is sufficient.

  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 'THE MAIN TOOL' and then states exactly what it does: 'Recommend games matching a stated preference, ranked against what the player actually plays.' It provides concrete examples of preference phrasing, making the tool's purpose unmistakable. It clearly differentiates from siblings by explicitly framing itself as the primary recommendation tool, distinct from search or comparison 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 description gives strong context: it explains the primary use case (matching a stated preference, with examples), notes that owned and wishlisted games are excluded by default, and mentions that it works without a Steam API key as a fallback. However, it does not explicitly state when to use alternatives like search_games or find_similar_games, so it stops short of full exclusion guidance. It provides clear context but no explicit 'when not to use'.

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