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

With no annotations to lean on, the description fully discloses behavior: it returns per-store status, an updated_at timestamp, a SHA-256 version for self-verification, and a 24h access_token. It also states the tool is paid (~$0.02) and that omitting payment_proof returns payment instructions rather than an error. This is transparent about cost, freshness, and verification.

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 dense but every sentence serves a purpose: the opening directive, the fallback warning, the return contents, exclusions, payment note, and access_token. It is front-loaded with the primary trigger phrase and avoids fluff despite its length.

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 that there is no output schema, the description compensates by enumerating the return value components (per-store status, updated_at, version hash, access_token). It also covers cost, freshness, self-verification, and the no-arg behavior, making the tool highly self-contained for an agent.

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 schema description already explains the payment_proof parameter ('Omit to receive payment instructions instead of data'). The tool description restates this behavior but adds no new format, constraints, or examples beyond the schema, so it stays at the baseline for fully documented parameters.

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: 'Returns every PC game currently free to KEEP (claim once, own permanently).' It clearly identifies the tool's scope (free-to-keep games on Steam, Epic, GOG, itch.io) and explicitly excludes free-to-play, demos, free weekends, sales, and giveaways, distinguishing it from sibling tools like get_upcoming and check_for_changes.

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 opens with 'USE THIS when asked what games are free right now' and provides explicit exclusions ('NOT for free-to-play games, demos, free weekends, sales, or giveaways you enter to win'). It also instructs the agent about the no-argument payment flow and warns against using training data, providing clear when-to-use and when-not-to-use guidance.

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