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 explicitly describes what is deleted and, importantly, what is preserved: Steam files are untouched and collection backups are preserved, which is valuable safety context. It does not discuss reversibility or post-clear system effects, though the core destructive behavior is clear.

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 compact and front-loaded: the first sentence states the core operation, and the second adds meaningful exclusions. There is no filler or redundant restating of the title.

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 tool with no output schema, the description plus schema is mostly sufficient to make a correct call. However, it does not connect to related cache operations like steam_cache_status or steam_cache_refresh, and it omits any note about the default scope behavior, so some practical context is missing.

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 description adds no parameter-level meaning beyond the schema. The dry_run parameter has a schema description, but the scope enum, including values like 'store-details' and 'store-reviews', is left entirely to the enum names, and the description does not explain how the default 'all' scope behaves.

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 action ('Delete') and resource ('this server's cached data') and further draws a clear boundary by stating Steam's own files are never touched and collection backups are preserved. This clearly differentiates it from status/refresh/library-related sibling 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 description gives no guidance about when to use this tool instead of steam_cache_status for inspecting cache or steam_cache_refresh for rebuilding it. There are no explicit conditions, prerequisites, or alternative tool mentions.

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 present, so the description carries the full burden of behavioral disclosure. It transparently surfaces rate limiting ('roughly one every 1.6s'), Steam's 200-per-5-minute limit, the 60-appid cap, and the multi-minute runtime. It does not clarify whether the refresh overwrites or clears existing cache data, but the key operational risks are disclosed.

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 sentences: the first front-loads the core action, the second explains constraints and duration. Every sentence provides necessary information with no redundancy or filler.

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 definition covers the main action, optional store pre-fetching, rate limits, and duration. With no output schema, a detailed return contract is not required. The only notable gap is the lack of explicit guidance on how the refresh affects existing cache state, but sibling tool names and the schema mitigate ambiguity.

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 documents all three parameters (force, library, store_appids) with descriptions and has 100% coverage, including maxItems for store_appids. The description adds a rate-limit note tied to store_appids, but this is a minor supplement rather than essential semantic clarification. Baseline 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 specific action: 'Re-read the library from Steam, and optionally pre-fetch store metadata for specific games.' This clearly identifies the resource (cached Steam library data) and the verb (re-read / pre-fetch). It is distinct from sibling tools in its combined behavior, though it does not explicitly differentiate itself from steam_cache_status or steam_library_list.

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 a fresh cache is needed, but does not explicitly state when to use it versus alternatives like steam_cache_status or steam_library_list. It does provide operational guidance—'at most 60 appids are accepted per call and the call can take a couple of minutes'—which helps an agent judge the cost of invocation.

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 present, so the description must carry the behavioral burden. 'Report' signals a read-only operation and 'how fresh' indicates the output is a freshness assessment rather than a mutation. However, it does not define what 'fresh' means (e.g., timestamp threshold) or state that it never triggers a refresh.

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 sentence in active voice with the key concept 'how fresh' front and center. There is no filler, no restatement of the title, and every word 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 parameterless tool the description is adequate, but with no output schema or annotations it leaves the exact response shape (timestamp? age? fresh/stale flag?) and freshness criteria undefined. A brief note on what the result provides would make it 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 tool has zero parameters, so the 100% schema coverage is trivially complete and there is no parameter burden for the description to carry. The description adds no parameter semantics, but none are 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 names a specific verb ('Report') and resource ('this server's cached library snapshot'), and 'how fresh' makes it unambiguous that this is a status/read operation. It does not explicitly contrast it with steam_cache_refresh or steam_cache_clear, but the wording is enough to distinguish it from them.

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?

There is no guidance on when to call this tool instead of steam_cache_refresh or steam_cache_clear, or what to do if the snapshot is stale. The purpose implies it is for checking freshness, but that is left to inference 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?

With no annotations, the description carries the behavioral disclosure burden. It usefully reveals that dynamic collections are refused and edits are silently reverted by Steam, which is valuable context. However, it does not mention permissions, side effects, dry_run behavior, or what happens with invalid collection identifiers.

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 sentences with no filler. The core action and the most important caveat are both front-loaded, and every clause contributes meaning.

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 description captures the main edge case and basic purpose, but with no output schema and no annotations, it leaves gaps: how to choose between id and name, what dry_run does, and what the tool returns. These are not fatal because the schema covers parameter basics, but the description alone is not fully 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?

Schema description coverage is 75%, so most parameters are already documented. The description adds the static-vs-dynamic distinction, which informs the collection identifier parameters, but it does not elaborate on dry_run or how id/name should be used together.

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 identifies the action ('Add games') and target ('existing static collection'), and the refusal of dynamic collections distinguishes it from the sibling remove/replace tools. It is specific and unambiguous 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 provides a clear usage context: use this for static collections, not dynamic/filter-based ones. It explicitly states the when-not case but does not name an alternative tool for other collection mutations, leaving some routing to inference.

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 and does well: it discloses that the tool never blind-creates, that existing same-named collections are reused and extended, and that Steam deletes duplicates during creation. It also notes the execution prerequisite of Steam running with debugging enabled. It does not describe output or error behavior, but the core mutation semantics are clear.

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 compact and front-loaded: the main purpose is stated first, followed by the critical duplicate-handling nuance and the prerequisite. Every sentence adds useful information without padding.

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 description covers the main behavior and prerequisite, but there is no output schema and no mention of return values or failure outcomes. Given the tool's mutation potential and the lack of annotations, some additional context about what happens on success or when Steam is not properly configured would make it more 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?

Schema coverage is 50%: dry_run and on_existing already have descriptions. The tool description adds some meaning for appids via 'optionally seeded with games,' but it does not elaborate on the name parameter or the exact meaning of appids beyond what the schema's type and property name imply.

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: 'Create a static collection, optionally seeded with games.' It also clarifies the non-obvious duplicate-name behavior, which clearly distinguishes this tool from adding games to an existing collection via a sibling tool.

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 clear context that this tool creates or reuses a collection and requires Steam running with debugging enabled. However, it does not explicitly mention alternatives or state when an agent should prefer a sibling tool like steam_collection_add_games instead.

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 behavioral burden. It clearly discloses that the collection and its id are permanently gone, that recreating it yields a new id, that games are unaffected, and that Steam backs up collection files. This is strong, safety-critical transparency.

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 front-loaded with the operation and packs warnings plus the safe invocation sequence into three short sentences. Every clause adds essential information; there is no filler.

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 destructive tool with no annotations and no output schema, it covers consequences, backup behavior, and the dry_run/confirm workflow well. The main gap is that it never explicitly says the collection must be identified via id or name, which is notable because confirm is the only required property in the schema.

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 documents all four parameters, providing a solid baseline. The description adds meaningful context about id lifetime—deleted collection ids are not reused—which goes beyond the schema, and it reinforces the roles of confirm and dry_run.

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 opens with a specific verb and object, 'Delete a collection', and immediately distinguishes this from sibling membership tools by noting the games themselves are untouched. There is no ambiguity about the resource acted on.

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 gives explicit safety steps: set confirm=true and run dry_run=true first to preview what will happen. It doesn't explicitly compare against alternatives like steam_collection_remove_games, but the deletion use case is clear from the context.

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 disclosure burden. It does state pagination, and 'Return' implies a read-only operation, but it does not specify error behavior, id/name precedence, or how include_games=false changes the result.

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 terse sentences with no filler. The core action is front-loaded, and the pagination note is the only additional behavior disclosed, earning 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?

Adequate for a simple fetch when combined with the schema, but with no output schema and no annotations, an agent still lacks return-shape cues and edge-case behavior. The description does not clarify what happens when both id and name are supplied or when include_games is false.

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 80%, with good inline descriptions for id, name, limit, and offset. The description adds little beyond hinting at 'with its games' for include_games, so it does not meaningfully compensate for the undocumented include_games parameter.

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 concrete verb ('Return') and identifies the resource ('one collection with its games'). 'One' helps distinguish this from steam_collections_list, though it does not name the sibling explicitly.

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 intended use is implied: fetch a single collection by ID or name. However, there is no explicit guidance about when to prefer this over collections_list or how to handle the id/name 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 provided, the description carries the behavioral disclosure burden. It does disclose the key safety-relevant behavior: games remain in the library and only membership changes. However, it does not explain dry_run behavior, whether the operation is reversible, or what happens when removing the last game from a collection.

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 short sentences with no filler. The action is front-loaded, and the clarifying behavioral caveat follows immediately, making it easy for an agent to parse.

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 description is complete enough for a basic call, and the schema covers most parameters. But with no output schema and no annotations, the tool would benefit from explaining dry_run semantics and when to use id versus name to identify the collection.

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 75%, so the schema already documents id, name, and appids in detail. The description adds no parameter-level meaning and does not clarify the undocumented dry_run parameter. This is an adequate but not enhanced 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 states a specific verb ('Remove') and resource ('games from a static collection'), and the clarifying clause 'The games stay in the library; only the collection membership changes' distinguishes this from library deletion or uninstallation. It effectively differentiates from sibling tools like steam_uninstall_game and steam_collection_delete.

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 conveys the action, but it does not explicitly say when to choose this tool over alternatives like steam_collection_add_games or steam_collection_replace_games. It implies usage for modifying collection membership but gives no exclusions or comparative 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?

With no annotations, the description carries the transparency burden. It discloses a key behavioral trait: the rename preserves id and membership. However, it does not mention ownership/permissions, error behavior, whether the operation is reversible, or the effect of the dry_run parameter.

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 short sentences with no filler. The primary action is front-loaded, and the second sentence provides a concise rationale that helps an agent make the right tool choice.

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 description is adequate for understanding what the tool does and why it is preferable to deletion, but it is incomplete for a mutation tool with no annotations and no output schema. Missing guidance on id vs name selection, dry_run behavior, and expected results leaves gaps 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?

Schema description coverage is only 50%; new_name and dry_run have no schema descriptions. The tool description does not compensate by explaining how to choose between id and name, what dry_run does, or how new_name relates to the other parameters. It adds no real parameter-level meaning 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 operation ('Rename a collection') and immediately clarifies the defining constraint ('keeping its id and membership'), which distinguishes it from create/delete-and-recreate among the sibling collection tools. It is not a tautology and adds meaningful scope.

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 explicitly names the alternative ('delete-and-recreate') and gives the condition that selects this tool ('your library shelf layout references collection ids'). This gives an agent clear guidance on when to prefer rename over destructive 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?

No annotations are provided, so the description carries the full disclosure burden and meets it well. It explicitly labels the operation DESTRUCTIVE, specifies what gets removed, and explains the confirm threshold and dry-run behavior. This gives an agent the critical safety context before invoking.

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?

Three tight sentences with no filler: core operation first, destructive warning second, and safety workflow third. Every sentence 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?

The description covers the action, destructiveness, confirmation guardrail, and dry-run workflow, which is nearly complete for a destructive 5-parameter tool. However, with appids as the only required field, it would benefit from explicitly saying that id or name must identify the collection, and there is no return-value context given the absence of an output schema.

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 only 60%, and the description adds important semantics for appids ('any game not in appids is removed'), confirm ('required when more than 10 games'), and dry_run ('see the diff'). The id/name identifier requirement is not explicitly stated, and the schema lists both as optional, so this could be clearer.

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 opens with 'Replace the entire membership of a collection,' which is a specific verb plus resource and directly distinguishes it from sibling add/remove tools. The destructive scope ('any game not in appids is removed') reinforces exactly 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 provides clear operational guidance: run dry_run=true first to see the diff and set confirm=true when more than 10 games would be removed. It does not explicitly name alternatives such as add_games or remove_games, but the usage context is otherwise 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 present, the description carries the behavioral burden, and it does well: it discloses that the tool reads the last state Steam wrote to disk when Steam is closedaddr degraded=true, and explains that dynamic collections are filter-based and therefore read-only. It does not explicitly state that the tool itself has no side effects, but the verb 'List' and absence of mutation language convey that.

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 sentences, no filler, and essential details are front-loaded. The parenthetical definition of dynamic is efficient, and every clause contributes either scope, return fields, or behavioral context.

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?

This tool has no output schema Earnings, but the description lists the returned fields and the degraded flag, which is sufficient for an agent to understand what it will receive. Both optional parameters are addressed or implied, and the stale-data behavior with Steam closed is explicitly disclosed, making this complete for a listing tool with no required 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 documents include_system, but include_dynamic has no schema description. The tool description partially compensates by defining what 'dynamic' means (filter-based, read-only), yet it does not explicitly explain how include_dynamic=true/false changes the result set. Thus it adds useful but incomplete parameter context.

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 immediately names the exact action ('List every library collection') and enumerates the fields returned: id, name, game count, dynamic status, and system status. It also distinguishes the two collection categories, making its scope clear and separating it from singular retrieval tools like steam_collection_get.

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 states that it can work with Steam closed by reading the last state from disk cancelled, which is useful context for when to call it. However, it does not explicitly mention alternatives or exclusions, such as 'for a single collection use steam_collection_get' or 'to modify collections use the add/remove/replace tools.'

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 and does well: it discloses on-demand store fetching, a two-week cache, a shared rate limit of ~200 requests per 5 minutes, and the recommendation to avoid loops. It doesn't cover error behavior or auth, but the core side-effect and performance traits are clearly stated.

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 sentences, with the tool's purpose front-loaded and the operational caveat following. No fluff, every clause contributes meaning, and the structure is easy to scan.

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-game detail tool with no output schema, it covers the key behavioral aspects (rate limit, caching, avoid loops) and enumerates the data returned. Missing details like the refresh flag's effect and the exact return shape are notable but not fatal, and the description is adequate for safe 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?

Schema description coverage is only 40% (only name and include_store have descriptions). The description adds context that store data is rate-limited and cached, which helps for include_store, but it doesn't explain refresh or include_reviews semantics. It partially compensates for the low coverage but leaves several parameters under-explained.

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 returns 'Everything known about one game' and enumerates specific data types (install state, playtime, tags, collections, store metadata). It distinguishes itself from sibling tools like library_list or library_search by focusing on a single game's aggregated details, so an agent can easily pick it for per-game queries.

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 gives a clear usage context: use for detailed info on one game, and warns against looping over many games due to the shared store request budget. It doesn't explicitly name alternative tools for list operations, but the scope is unambiguous, and the rate-limit guidance provides practical when-to-use/avoid 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?

With no annotations provided, the description carries the full burden, and it does well by disclosing that this is not a silent install, that the wizard must be manually clicked through, that nothing happens until then, and that the tool returns before the download actually starts. It does not mention potential side effects like disk usage or Steam account restrictions, but the core non-obvious behavior is clearly disclosed.

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 four sentences and every sentence earns its place: the core action, the critical warning against assuming silent install, the manual-click behavior, and the follow-up verification step. It is front-loaded and waste-free.

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 description explains what the tool does, why it is not silent, how to verify success, and that it returns immediately after opening the wizard. It does not specify the exact return value format, but the lack of an output schema and the simple 'returns as soon as the wizard is open' wording make this acceptable. The guidance to check steam_game_details later fills the main follow-up gap.

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 67%, and the schema already explains confirm's purpose and dry_run's behavior. The description adds no additional parameter-level detail, and appid remains minimally documented, but the schema provides enough information for the agent to use the parameters correctly. This is a baseline score for a tool where the schema does most of the parameter work.

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 and resource: 'Open Steam's install wizard for a game.' It also explicitly distinguishes this from a silent install, and it is clearly differentiated from sibling tools like steam_uninstall_game and steam_game_details. The agent can infer exactly what action this tool performs.

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 explains what to expect when using the tool: it opens a dialog that must be clicked through manually, and it returns before the download starts. It also instructs to check steam_game_details later to verify whether the download actually began. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to decide appropriately.

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 burden and discloses non-obvious facts: results are compact, paginated, never a full dump, hidden games are excluded by default, and 'total' must be checked. These are exactly the behaviors an agent could miss and then misread partial results.

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?

Three short sentences, front-loaded with the core purpose followed by high-value caveats. No filler; the apparent redundancy between 'compact projection' and 'never dumps the whole library' reinforces an important behavioral constraint.

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 20-parameter tool with no output schema, the description covers the most critical operational hazards: pagination, hidden-game default, and the need to inspect 'total'. It leaves some return-shape details to inference, but the schema's field defaults and the description's caveats cover enough 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?

Schema description coverage is 60%, and the description adds some parameter-relevant meaning (hidden behavior, pagination, compact projection), but it does not compensate for the many undocumented params like sort, order, or the min/max filter fields. It is adequate only because parameter names are largely self-explanatory.

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?

States a specific action ('list, filter and sort') applied to a specific resource ('games in the Steam library') and immediately adds differentiating traits: compact projection, pagination, and hidden-game exclusion. This lets an agent distinguish it from sibling detail/search tools without opening the schema.

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?

Provides clear context that this is the paginated, filterable library listing tool, and explicitly calls out the hidden-game default. It does not name alternatives like steam_library_search or steam_recently_played, so it stops short of full when-to-use vs. not 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal core search behavior—fuzzy matching, punctuation-insensitivity, and best-first ranking. It does not discuss empty results, read-only guarantees, or output shape, but these are less critical for a lookup-style tool.

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 sentences with no wasted words. The core behavior is front-loaded, and the use case is stated in the final sentence. Every sentence 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?

The description covers purpose, matching behavior, and the appid use case, which is enough for a bare query call. However, with no annotations and no output schema, it leaves the non-query parameters and the exact return format underspecified, so agents using filters or expecting a structured response are not fully equipped.

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 0%, so the description must compensate, but it only clarifies the query concept. The limit, include_hidden, and installed_only parameters are not explained at all beyond their names and defaults, leaving agents without meaningful guidance for filtering or pagination.

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 opens with a precise verb and resource: 'Find games by name.' It then adds differentiating behavior—'Fuzzy and punctuation-insensitive, ranked best-first'—and connects the tool to its role in appid lookup, setting it apart from library list/detail siblings.

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 explicitly states when to use the tool: 'Use this to turn a game name into an appid before calling any tool that takes appids.' It gives clear context but does not explicitly state when not to use it or name alternatives, so it stops just short of full routing 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 present, so the description must carry the behavioral burden. It does disclose the sort order ('newest first') and the temporal scope, but it does not explicitly state that the operation is read-only, nor does it describe the return shape or any side effects.

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 extremely concise and front-loaded: 'Games played recently, newest first' packs the resource and ordering in eight words with no filler. Every word 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 list tool with one optional parameter, the description is nearly enough: it tells the domain and order. However, with no annotations and no output schema, it leaves the read-only nature, the list return type, and the limit behavior implicit, making it minimally viable rather than fully 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 only parameter, limit, is documented in the schema with type, default, minimum, and maximum, but the description does not mention it at all. With schema description coverage at 0%, the description was expected to compensate and explain how limit affects the result set, but it does not.

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 identifies the resource (recently played games) and adds the ordering detail 'newest first.' It is distinguishable from siblings like steam_library_list or steam_game_details by the 'recently played' scope, though it lacks an explicit verb such as 'List' or 'Retrieve.'

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?

No guidance is given about when to use this tool over alternatives such as steam_library_list or steam_library_search. There are no stated exclusions, prerequisites, or context signals to help an agent choose between this and the many sibling tools.

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, and it delivers richly. It warns that Steam will close, that running games will be interrupted, that unsaved progress may be lost, that the tool refuses to run when a game is detected unless allow_interrupt_game is set, and that the operation typically takes 25-60s. For a destructive, side-effect-heavy tool, this is exemplary transparency.

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 compact, with no filler. The action is front-loaded first, followed by a prominent warning, the conditional refusal rule, the use-case trigger, and a timing estimate. Every sentence earns its place and contributes either to selecting the tool or understanding its impact.

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 a destructive restart operation with no annotations and no output schema, the description covers everything an agent needs to safely decide and call: what happens, when it is required, what can go wrong, how to override the safety guard, and how long it takes. No critical operational detail is missing.

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 documents all 5 parameters with 100% coverage, so the baseline is 3. The description adds meaning beyond the schema by explaining the refusal behavior tied to allow_interrupt_game ('the tool refuses to run if it detects a game, unless allow_interrupt_game is set') and by framing the operation as a prerequisite for collection writes. This situational context helps an agent reason about parameter trade-offs, pushing it above 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 opens with a specific and concrete behavior: 'Quit Steam and relaunch it with its Chromium debugger enabled, then wait for the library UI to finish loading.' This clearly identifies the operation on a specific resource and distinguishes it from the many sibling read/write tools like steam_status and steam_collection_create. The title and description align, leaving 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 provides an explicit trigger condition: 'Required before any collection write when steam_status reports collections_write unavailable.' It also gives a clear when-not-to-use warning about running games and explains the safety escape hatch (allow_interrupt_game). This is practical, actionable guidance that tells an agent exactly when to invoke the tool and what to check 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does state that the tool can both add and remove favorites, but it omits important behavioral details such as permissions, side effects, reversibility, dry_run behavior, and what the response looks like. For a mutation tool, 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 a single, front-loaded sentence with no redundant content. It efficiently communicates the core operation without wasting 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?

For a state-changing tool with no annotations and no output schema, the description is too thin. It does not explain dry_run semantics, when to prefer this over other sibling tools, or what error or return behavior to expect, leaving an agent without enough context for safe 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 schema already documents appids and value, but the description adds no additional meaning for them. More importantly, the dry_run parameter is not described in either the schema or the description, and the description does not compensate for this gap.

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 action ('Add games to, or remove them from') and the specific resource ('Steam's Favorites collection'). This distinguishes it well from sibling tools like steam_set_hidden or the collection management tools, whose purposes are different.

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: it is clearly about managing the Favorites collection. However, it does not explicitly say when to use this tool versus alternatives like collections or hidden flags, nor does it provide any exclusion 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?

With no annotations, the description carries the behavioral disclosure burden. It does reveal a non-obvious side effect: the change applies account-wide across all devices. However, it does not explain dry_run behavior, return values, or failure modes, so the disclosure is only partially complete.

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 short, front-loaded sentences communicate the action and the key side effect with no wasted words. The structure is highly scannable for an agent.

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 operation itself is simple and the account-wide effect is stated, which is valuable. But the tool has no output schema and no annotations, and the dry_run parameter is undocumented, leaving some gaps for an agent deciding how to invoke it safely.

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 description adds no parameter-level meaning beyond the schema. The schema already documents value and appids, but dry_run is left completely undescribed. With 67% schema coverage and no compensating description detail, the dry_run parameter remains ambiguous.

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 ('Hide games from the Steam library, or unhide them') and clearly communicates the bidirectional action. It is easy to distinguish from sibling tools like steam_set_favorite or steam_library_list.

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 relevant context by noting the change affects the library view on every device signed into the account, which is an important consideration. It does not explicitly name alternatives or provide when-not-to-use guidance, but no sibling tool performs the same hide/unhide function.

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 burden. It discloses a key trait: 'Never fails - it reports problems instead of throwing,' which tells the agent how to interpret failures. It does not fully detail data source semantics, but the failure-mode guarantee adds genuine transparency.

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?

Three sentences with no filler. The first sentence front-loads the core purpose, the second states a critical invariant, and the third gives a concrete usage directive. Every sentence 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 low-complexity status tool with a single optional parameter, the description is complete. It tells the agent what the tool reports, how errors behave, and when to call it. No output schema exists, but the description enumerates the reported categories well enough to set expectations.

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?

There is only one parameter, and the input schema already explains it fully, including the live-connection behavior and the ~2s cost. The tool description adds no parameter-level detail beyond the schema, so baseline 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 ('Report') and names exactly what is reported: Steam client state, debugger reachability, usable data sources, and available capabilities. This is clearly distinct from sibling tools that manage library entries, collections, or cache state.

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 an explicit trigger: 'Call this first whenever a Steam operation is unexpectedly unavailable.' It does not name alternatives or say when not to call it, but the directive is clear enough to route an agent to this tool at the right time.

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. It describes the core behavior (listing tags with counts) but does not mention that results are affected by the 'limit' and 'min_count' parameters, nor any other behavioral details like pagination or ordering. This is a minor gap for a simple 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.

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

Two sentences, front-loaded with the primary action and then a direct usage note. 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?

For a simple list tool with two parameters and no output schema, the description provides the essential context: what it returns and why you'd use it. It doesn't describe the output format but that is implied. It's sufficient 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.

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

Schema coverage is 0% and the description does not explain the parameters 'limit' or 'min_count'. While the names are somewhat self-explanatory, the description fails to add meaning beyond the schema, especially 'min_count' which could be ambiguous.

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?

States a specific verb ('List') and resource ('store tags across the library') with a count per tag, and explicitly ties it to the 'tag' filter of steam_library_list, differentiating it from siblings like steam_library_list and steam_library_search.

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?

Explicitly states the intended use: to discover valid values for the 'tag' filter of steam_library_list. This gives clear when-to-use guidance, though it doesn't mention exclusions or alternatives beyond that.

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 and does a superb job: it discloses the non-silent dialog behavior, the irreversible deletion, save-file consequences, and the Steam Cloud exception. It even calls out the confirm requirement, going well beyond minimal safety warnings.

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?

Four crisp sentences, front-loaded with the core action and using the rest for essential warnings. 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.

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

For a destructive tool with no annotations and no output schema, the description covers action, interaction model, irreversibility, save implications, and the confirmation contract. dry_run is already explained in the schema, so nothing necessary for correct invocation is missing.

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 documents confirm and dry_run with descriptions, and the description only repeats the confirm=true requirement without adding new detail. appid is left without added meaning, though 'for a game' loosely ties it to the tool's purpose. With 67% schema coverage, the description adds only marginal parameter value.

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 ('Open') and resource ('uninstall wizard for a game'), and the 'NOT silent' note immediately clarifies that this does not perform a hidden uninstall. It clearly distinguishes itself from the sibling steam_install_game by naming the uninstall direction.

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 clear context: use this to uninstall a game, with an explicit caveat that it is not silent and opens a manual dialog. It does not name an alternative or state an explicit when-not-to-use, but the context is sufficient for an agent to select it appropriately.

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 full behavioral burden. It adds the API-key prerequisite, and the read-only nature is implied by 'List', but it doesn't describe pagination behavior, error cases, or return shape. This is a modest addition over the schema.

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 sentences, with the core action first and the prerequisite second, containing 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?

For a simple read-only listing tool, the API-key note plus schema may be enough to issue a correct call, but the absence of an output schema and any pagination/return description creates a gap. Sibling differentiation is also absent, so an agent must rely on the name alone.

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?

Both limit and offset are fully documented in the schema with defaults and bounds (100% coverage). The description adds no parameter-specific meaning, so the baseline 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?

States a specific verb 'List' and resource 'wishlisted games', which is distinct from library- and collection-based sibling tools. Title reinforces the resource. No ambiguity.

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 only contextual note is the STEAM_API_KEY prerequisite; there is no discussion of when to prefer this tool over steam_library_list or steam_library_search. Selection must be inferred from the name.

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