Refresh cached Steam data

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.