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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It does reveal that the tool aggregates data from two sources and returns metadata plus visual assets in one request, which is useful, but it does not describe return structure, failure modes, or source-priority behavior.

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

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

The description is two sentences with no redundancy. The core behavior and data sources are front-loaded, and the recommendation is concise and actionable.

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

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

Given the simple one-parameter schema and read-only nature implied by 'Get,' the description provides sufficient context for an agent to invoke the tool correctly. It lacks an output schema, but the mention of metadata and specific visual asset types gives a reasonable picture of what will be returned. A bit more detail about response contents would push it higher, but it is not necessary for basic invocation.

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

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

The single parameter 'query' is fully described in the schema as 'The game name to search for,' so schema coverage is 100%. The description adds no additional parameter-level guidance, which matches the baseline of 3 when the schema already handles parameter semantics.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource: a comprehensive game profile combining Steam metadata with SteamGridDB visual assets. This distinguishes it from sibling tools like steam_get_details or steamgrid_get_assets by emphasizing aggregation into a single request.

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

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

The description states it is 'the recommended tool for getting a complete overview of a game,' which gives a reasonably clear use case. It does not explicitly enumerate alternatives or exclusions, but the context of when to choose this tool is apparent from the 'complete overview' framing.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns metadata and media assets, but it does not disclose important behaviors: whether it requires authentication/API key, rate limits, network dependency, whether it can fail when no match is found, or whether it performs a remote API call. For a tool that fetches external data, this is a significant gap.

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

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

The description is two sentences, front-loading the core purpose and then listing search methods and return types. It is efficient and free of fluff. It could be slightly more structured (e.g., separating search methods from return types), but it earns its place with no wasted words.

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

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

With 9 parameters, no required fields, no output schema, and no annotations, the description is not complete enough. An agent cannot tell which parameters are mutually exclusive, which are required for a successful lookup, or what the response structure looks like. The tool's complexity (multiple search modes, external API) demands more guidance than the description provides.

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

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 all 9 parameters. The description adds the high-level concept that parameters can be used as search methods (ID, name, checksums), which is useful. However, it doesn't clarify relationships between parameters (e.g., whether systemId is required for name searches, whether checksums are preferred over names, or how language affects output). Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: retrieving detailed information and media assets for a retro game from ScreenScraper.fr. It specifies multiple search methods (game ID, name, ROM checksums) and the types of metadata returned (screenshots, covers, wheels, videos). This distinguishes it from sibling tools like screenscraper_search_game (which likely only searches) and steam_* tools (which are for Steam, not retro games).

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

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

The description implies usage by listing search methods, but it does not explicitly state when to use this tool versus alternatives like screenscraper_search_game or game_get_full_profile. It doesn't provide conditions like 'use this when you have a ROM checksum' or 'use screenscraper_search_game when you only need a game ID'. The context is clear for a retro game lookup, but exclusions and alternative routing are absent.

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

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

No annotations are provided, so the description carries the full burden. It discloses the operation and the return fields (system IDs, names, manufacturers, supported file extensions), which is good, but it does not mention response format, rate limits, sorting, or whether the list is paginated. Adequate for a simple list operation but not rich.

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

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

The description is concise: one topic sentence followed by a precise list of returned fields. There is no filler, redundancy, or unnecessary detail.

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

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

For a parameterless list endpoint without annotations or an output schema, the description tells the agent exactly what to expect: a list of systems and their attributes. Nothing critical is missing for correct invocation or result interpretation.

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

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

The tool has zero parameters, so the baseline is 4. The description adds meaningful information about what the returned data contains, which compensates for the lack of an output schema.

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

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

The description states a specific action ('Get a list') and a specific resource ('supported retro gaming systems'), and clarifies it is about the system catalog rather than game-level data. This distinguishes it clearly from the sibling screenscraper_search_game and screenscraper_get_game_info tools.

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

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

The intent is obvious: use this when the agent needs the full catalog of supported systems, not a specific game lookup. It does not explicitly name alternatives or exclusions, but the no-parameter design and system-focused wording make the usage context clear.

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

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

With no annotations provided, the description carries the behavioral burden. It states that the tool returns game information including system, developer, publisher, and genres, which clarifies the result behavior. However, it does not mention rate limits, error behavior, pagination, or whether the search is exact or fuzzy, leaving some behavioral gaps.

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

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

The description is a single, efficient sentence pair that front-loads the main purpose and then adds the optional filter and return fields. Every clause earns its place with no filler or redundancy.

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

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

For a simple search tool with three parameters and full schema coverage, the description is mostly sufficient. It names the key return fields, but with no output schema it leaves the shape of the result (e.g., list vs. single item, pagination, match scoring) unclear, and it does not guide the agent toward screenscraper_get_game_info for detailed follow-up.

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

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 all three parameters. The description adds the overall semantics of 'by name' and 'optionally filter by gaming system,' but does not add meaning beyond what the schema already provides, 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.

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

The description uses a specific verb-resource pair: 'Search for retro games on ScreenScraper.fr by name.' It also names the optional system filter and the fields returned, making it easy to distinguish from sibling tools like steam_search_game or screenscraper_get_game_info.

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

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

The description implies usage: use it to search by name and optionally filter by system. However, it does not explicitly state when to prefer this over screenscraper_get_game_info or when not to use it, nor does it mention any exclusions or prerequisites beyond the schema's hint to use screenscraper_get_systems.

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

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

With no annotations, the description carries the behavioral disclosure burden. 'Get' clearly implies a read-only operation and the description lists what is returned. However, it does not disclose potential errors, rate limits, authentication needs, or behavior for invalid App IDs, though these gaps are less critical for a simple getter.

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

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

One single, front-loaded sentence states the action, the input key, and the output scope. There is no redundant phrasing or filler, and the list of metadata fields earns its place by clarifying what 'details' means.

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

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

For a one-parameter read tool with no output schema, the description covers the essential call context: what to provide and what to expect back. It does not describe the response structure, but the enumerated return fields give sufficient guidance for an agent to decide if this tool fits.

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

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

The input schema already describes appid as 'The Steam App ID of the game' with 100% coverage. The description adds no further semantic detail about appid format, provenance, or constraints, so it provides no value beyond the schema baseline.

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

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

The description clearly states the verb 'Get' and the resource 'detailed information about a Steam game by its App ID', and enumerates the metadata returned. It does not explicitly distinguish itself from siblings like steam_get_dlc_list or game_get_full_profile, but the scope is specific enough to infer the difference.

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

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

The description implies the tool should be used when an App ID is known and comprehensive game metadata is needed. However, it gives no explicit guidance about when not to use it, nor does it mention alternatives such as steam_search_game for finding an App ID first.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It conveys that this is a read/list operation and specifies exactly what is returned: App ID and name for each DLC. It stops short of detailing edge cases like invalid App IDs or pagination, but for a simple list retrieval this is adequate.

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

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

The description is one clean sentence that front-loads the action, scopes it to a specific game, and includes the return contract. Every word earns its place with no redundancy.

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

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

For a single-parameter tool with no output schema, the description is fully sufficient: it explains the purpose, the input, and the shape of the result. Nothing critical is missing for an agent to decide whether to call it and what to expect.

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

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

Schema description coverage is 100%: the single parameter appid is already described as 'The Steam App ID of the main game'. The tool description adds little beyond that, so the schema does the heavy lifting and the baseline of 3 applies.

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

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

The description uses a specific verb ('Get') with a specific resource ('list of all available DLCs') and clearly identifies the required input ('Steam game by its App ID'). It also states the return payload (App ID and name for each DLC), which distinguishes it from siblings like steam_search_game or steam_get_details.

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

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

The description makes it clear that the tool is for retrieving DLC for a specific Steam game via App ID, which implies when it should be used. It does not explicitly name alternatives, but no sibling tool targets DLC lists, so the usage context is clear and exclusions are unnecessary.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that this is a read-only operation, whether it requires authentication, rate limits, or what the response format looks like. The description only states the basic action, leaving the agent without important behavioral context.

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

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

The description is a single, concise sentence that front-loads the core purpose. It earns its place without unnecessary detail, though it could add a bit more context without becoming verbose.

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

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

For a tool with no annotations and no output schema, the description is too thin. It does not explain the return structure, pagination behavior, or any edge cases like invalid appids. An agent would need to infer too much to use it correctly in varied contexts.

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

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. The description adds no extra meaning beyond the schema, but the baseline of 3 is appropriate because the schema fully covers parameter semantics.

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

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

The description states a clear verb ('Get') and resource ('latest news and announcements for a specific Steam game'), which distinguishes it from sibling tools like steam_get_details or steam_get_reviews_summary. It could be slightly more specific about the news feed source, but it is unambiguous enough.

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

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

The description implies usage for fetching game news but does not explicitly state when to prefer this over alternatives or mention any exclusions. Sibling tools cover other game data, so an agent can infer the use case, but there is no direct guidance on 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.

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

With no annotations available, the description carries the full burden. It transparently indicates this is a read-only list-returning tool. It does not describe output format or ordering, but for a zero-parameter discovery list, those are minor omissions rather than significant behavioral gaps.

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

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

A single, tightly written sentence conveys the action, the resource, and the intended purpose without wasted words. It is front-loaded and 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.

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

Given the zero-parameter schema, no annotations, and no output schema, the description is sufficiently complete: it states what the tool returns ('a list of common Steam genres and categories') and for what purpose ('discovery'). No additional context is necessary for correct invocation.

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

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

The tool has zero parameters, so there is nothing meaningful for the description to add beyond the schema. The baseline of 4 applies because schema coverage is complete and no parameter documentation is needed.

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

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

The description clearly states a specific action ('Get a list') and a specific resource ('common Steam genres and categories for discovery'). It is distinct from sibling tools like steam_search_game or steam_get_details, which target search and game metadata rather than genre discovery.

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

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

The phrase 'for discovery' provides a clear use case, and there is no competing sibling tool that retrieves genres/categories. It does not explicitly state when not to use it, but the uniqueness of the tool makes the intended usage reasonably obvious.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool returns the current number of players online, but does not mention whether authentication is required, potential rate limits, or the nature of the response. This is a minimal disclosure for a tool with no annotation coverage.

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

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

The description is a single, focused sentence with zero unnecessary words. It is front-loaded with the core action and resource, making it immediately actionable.

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

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

For a simple tool with one parameter and no output schema, the description adequately conveys the return value (the player count) without needing to detail the exact format. It is complete enough for an agent to understand what to expect, though it could optionally mention response format or potential edge cases.

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

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

Schema coverage is 100% for the single parameter appid, which is fully described in the schema. The description adds no additional meaning beyond what the schema already provides, only referring to 'a specific Steam game' which maps to appid. Baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Get' and the resource 'current number of players online for a specific Steam game', which is precise and distinguishes it from sibling tools like steam_get_details or steam_search_game. No ambiguity about what the tool does.

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

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

The description implies usage—when you need the player count for a game—but it does not explicitly state when to use this tool versus alternatives or any exclusions. The purpose is so specific that usage is self-evident, but there is no explicit guidance or mention of alternatives.

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

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

With no annotations, the description carries the full burden. It indicates a read-only 'Get' operation and describes output contents, but it does not mention error behavior, rate limits, or the exact shape of the response, leaving some behavioral ambiguity.

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

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

Two compact sentences that state the action, target, and output contents with no filler or repetition.

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

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

The tool is simple (one parameter, no output schema), and the description adequately sets expectations by naming the outputs: overall score and top review snippets. It could include response-format details, but nothing critical is missing for invoking it correctly.

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

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

Schema coverage is 100% and the appid parameter is already described as 'The Steam App ID of the game.' The description only restates this ('by its App ID'), adding no new semantic detail beyond the schema.

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

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

The description names a specific resource ('user reviews and ratings for a specific Steam game by its App ID') and states what is returned ('overall score and top review snippets'). This clearly distinguishes it from sibling tools like steam_get_game_news or steam_get_details.

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

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

It is clear you should call this when you have an App ID and want review/rating summary data, but there is no explicit guidance about when not to use it or which sibling tool to prefer (e.g., steam_get_details for full metadata). The context is implied rather than stated.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It does not explain what 'top' means, how games are sorted, whether genreId is resolved as a name or ID, or what happens when no genreId is provided. The description only names the operation without revealing behavior.

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

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

The description is a single focused sentence, with no filler or repetition. It front-loads the core purpose and includes useful examples in a compact way.

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

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

For a simple two-parameter list tool, the description plus schema is minimally sufficient. However, with no annotations and no output schema, it leaves gaps around what 'top' means, the effect of an omitted genreId, and the shape of the response.

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

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

The schema descriptions provide 100% coverage for both parameters, including the default for limit and the name-or-ID nature of genreId. The description adds slight value with genre examples and the phrase 'category or genre', but it does not significantly extend the schema semantics.

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

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

The description clearly states the tool's function: browsing top games for a specific Steam category or genre. It gives concrete examples like 'Action', 'RPG', and 'Strategy', which makes the resource and scope easy to identify. However, it does not explicitly differentiate from the sibling tool steam_get_top_sellers.

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

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

The description provides a clear use case: when you want to browse top games within a specific category or genre. It does not mention alternatives or exclusion criteria, but the context is explicit enough that an agent can infer when to invoke it.

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

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

With no annotations, the description carries the behavioral disclosure burden. The phrase 'current global' adds context that the result is a live, geographically broad snapshot, and 'get' implies a read-only operation. However, it does not disclose the output format, sorting logic, or whether authentication or rate limits apply.

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

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

The description is a single, focused sentence with no filler or redundancy. Every word contributes meaning, and the tool's core purpose is immediately clear.

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

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

The tool is simple and the schema covers its one parameter, but the description is thin for an agent selecting between similarly named siblings. It does not clarify how 'top sellers' differs from the sibling 'steam_get_top_games', and with no output schema or annotations, the description alone leaves some ambiguity about the exact result shape and selection criteria.

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

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

The schema already describes the only parameter, 'limit', including its default, so schema description coverage is 100%. The description adds no parameter-level information, but none is needed beyond the schema. The baseline of 3 applies.

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

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

The description states a clear verb and resource: 'Get the current global top selling games on Steam.' It clearly describes what the tool does. However, it does not explicitly distinguish this from the sibling tool 'steam_get_top_games', so the differentiation is left to the name and inference.

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

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

The description provides no guidance on when to choose this tool over its siblings, particularly 'steam_get_top_games'. There is no mention of alternatives, exclusions, or context such as 'use this for sales-based rankings rather than player-based rankings.'

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool returns URLs; it does not describe the response structure, failure modes, empty results, rate limits, or that this is a read-only operation beyond the 'Get' verb.

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

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

One concise, front-loaded sentence communicates the verb, resource, and return output without filler. Every part earns its place.

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

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

For a simple read operation with two parameters and full schema coverage, the description is minimally adequate: it says what the tool does and what it returns. However, with no output schema and no guidance on choosing this over steamgrid_get_best_logo, the description leaves some ambiguity about return format and alternative usage.

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

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

Schema description coverage is 100%, so both gameId and assetTypes are already documented. The description loosely lists asset types that match the schema enum, but it adds no additional meaning, syntax details, or context beyond what the schema provides.

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

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

The description uses a specific verb and resource: it gets visual assets from SteamGridDB for a game. It also names the asset categories (logos, boxart/grids, hero images, icons), which clarifies the tool's scope. However, it does not explicitly distinguish itself from the sibling steamgrid_get_best_logo, so it falls just short of full sibling differentiation.

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

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 instead of alternatives such as steamgrid_get_best_logo, nor does it explain when to restrict assetTypes. The intended use is implied by the name and schema but never stated explicitly.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It implies a read-only operation via the verb 'Get', but it does not clarify what 'best' means (e.g., highest resolution, most downloaded), nor does it mention any edge cases such as requiring at least one of the two IDs. The lack of explicit disclosure about the selection criteria and potential failure modes leaves behavioral transparency at a baseline level.

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

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

The description is a single, concise sentence that directly states the tool's function without any unnecessary words. It is front-loaded with the core action and object, and every word contributes meaning. This is an example of excellent conciseness.

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

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

The tool is relatively simple, but the description leaves gaps: it does not explain which ID (appid vs. gameId) is required or how they relate, nor does it describe the return format (e.g., a URL or image data). Since there is no output schema, the description must convey the expected response, which it fails to do. The absence of annotations also means the agent lacks safety and side-effect context. These gaps make the description minimally complete for a tool with two optional parameters.

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

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

The schema already provides descriptions for both parameters (appid and gameId) with 100% coverage, so the baseline is 3. The tool description adds no additional meaning about how the parameters relate or which one takes precedence. Since both are optional, an agent may be confused about whether to provide one, both, or either. The description does not clarify this, so it does not elevate parameter semantics beyond the schema.

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

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

The description states a specific verb (Get) and a specific resource ('single best transparent logo') from a named source (SteamGridDB). It clearly conveys what the tool returns, but it does not explicitly differentiate it from the sibling tool steamgrid_get_assets, which likely returns multiple assets including logos. The purpose is clear but lacks direct sibling differentiation, so a 4 is appropriate.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention that steamgrid_get_assets might be used when multiple logos are needed, nor does it state prerequisites like needing either an appid or gameId. The usage context is implied by the tool name but not explicitly stated, so it falls short of clear guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the output type (a list of games with IDs) but lacks any information on rate limits, authentication, pagination, or side effects. As a search tool it is presumably read-only, but that is not stated. The description provides minimal behavioral context beyond the obvious.

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

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

The description is a single, efficient sentence that front-loads the action and resource, then adds the key outcome. No redundant or filler content, every word contributes to understanding.

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

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

For a simple one-parameter search tool with no output schema, the description adequately explains what it does and what the result looks like. It does not mention optional filters or edge cases, but none are implied by the schema. Given the simplicity, the description is nearly complete.

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

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

The schema description for 'query' is already clear ('The game name to search for') and covers 100% of the single parameter. The description adds no further parameter-level details, only reiterating that the search is by name. Baseline of 3 is appropriate given high schema coverage.

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

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

The description clearly states a specific action ('Search') on a specific resource ('video games on SteamGridDB') and explains the result (list with IDs for retrieving assets). This distinguishes it from sibling tools like steam_search_game, which searches the Steam store, by explicitly naming SteamGridDB as the data source.

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

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

The description implies usage for retrieving visual assets by noting the IDs can be used for that purpose, but it does not explicitly state when to use this tool versus alternatives like steam_search_game or provide any exclusions. Usage guidance is implied rather than explicit.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states that it returns a list, without mentioning read-only status, rate limits, pagination, or edge cases. For a search operation, this is minimal and does not add context beyond the obvious.

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

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

The description is a single, front-loaded sentence that states purpose and return value with zero wasted words. It is appropriately concise for a simple search tool.

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

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

For a simple two-parameter search tool with complete schema coverage and no output schema, the description is functionally adequate. It conveys the core purpose and return. However, it does not mention any caveats, such as the read-only nature, result ordering, or how to chain with other tools like steam_get_details. These gaps are minor given the low complexity but prevent a higher score.

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

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

The schema covers both parameters (query and limit) with descriptions, so the baseline is 3. The tool description adds no additional meaning about the parameters—it does not clarify the query format, limit behavior, or how they interact. The schema already handles this adequately.

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

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

The description states a specific verb ('Search'), a clear resource ('video games on Steam'), and the expected return ('a list of matching games with their App IDs'). This clearly distinguishes it from sibling search tools like steamgrid_search_game and screenscraper_search_game by naming the platform (Steam).

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

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

The description clearly implies when to use this tool (when you need to find a Steam game by name), but it does not explicitly mention alternatives or when NOT to use it. No exclusions or comparisons with sibling tools are given, leaving the agent to infer the appropriate context.

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