SteamCozy

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds genuine behavior beyond that: the return format (Markdown), the per-field as-of dating convention, and a real availability constraint (adult-only titles excluded). No auth or rate-limit notes, but the added context is substantive.

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 front-loaded sentence with the identity and identifier source first, followed by the payload enumeration and the adult-titles caveat. The return-field enumeration is long, and since an output schema exists it is partly redundant, costing a point on leanness.

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 rich annotations, an output schema, and a fully documented single parameter, the description only needs to add identity, sourcing, scope and constraints — all of which it does. Nothing required 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?

Schema description coverage is 100% and the single 'id' parameter is already documented in the schema with the same app-id/slug example. The description repeats that meaning rather than extending it, 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 ('Read') and resource ('one Steam game's record from steamcozy.com') and pins the identifier source ('id from search/find_games ... or its slug'). An agent can distinguish it from find_games, search and new_games purely from this sentence.

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 routes the agent: the id comes from search/find_games, and it states the exclusion that adult-only titles are unavailable. It stops short of naming an alternative tool for those blocked cases or stating when to prefer search over fetch, so it is strong routing rather than full when/when-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?

Annotations already declare this a safe, idempotent, read-only, open-world operation, so the safety burden is lifted. The description adds real behavioral context beyond that: tags are ANDed rather than ORed, results are ordered by tag prominence then popularity, and adult-only titles are never returned.

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 tightly packed sentences lead with the primary action, then qualification rules, then filters and ordering guarantees. Every clause carries distinct information (AND semantics, ordering, adult exclusion) with no redundancy against the schema.

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?

An output schema exists, so return-value description is unnecessary. For a 7-parameter, zero-required discovery tool the description covers the composition rules, ordering, and exclusion policy; only cross-tool routing guidance is absent.

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 baseline is 3. The description goes beyond the schema by clarifying that all supplied tags must apply, that 'like' consumes a Steam app id resolved via precomputed similar games, and that review-count and positive-% floors are optional filters rather than requirements.

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+resource (discover Steam games) and enumerates the two discovery modes: community tags and 'like' similarity. It is clear about what the tool does, but never names or contrasts with the siblings (fetch, new_games, search), so an agent must infer the boundary from the description alone.

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?

Usage is implied through the tag/like combination mechanics ('up to 4, all must apply', 'and/or'), which tells the agent how the modes compose. However, there is no explicit guidance on when to choose this tool over new_games or search, and no stated exclusions or prerequisites.

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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuine behavioral context the annotations cannot convey: 'popular' is order-only with no sales numbers and is re-baked daily, 'just_released' applies a review floor, and 'steam_chart' reflects the previous month's gold/silver/bronze tiers.

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 front-loaded sentence plus an inventory sentence; the block definitions come first and the item-shape note comes last. It is dense with parentheticals but nearly every clause carries distinguishing information, so little is wasted.

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?

An output schema exists, so return values need not be detailed, and the description still sketches item contents (link, review score, tags). With a single optional enum parameter and full schema coverage, an agent has everything needed to call it correctly; only cross-tool routing is unstated.

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 enum values are already listed, so the baseline is 3. The description goes further by defining what each enum value actually contains (this week and last with a review floor, Early Access graduates, cozy releases, prior-month chart tiers), which is real semantic value 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 the concrete resource (this month's Steam releases as shown on steamcozy.com/new) and enumerates the five block categories with their exact semantics, so an agent knows precisely what it fetches. It does not explicitly contrast itself with the siblings fetch/find_games/search, which keeps it just short of a 5.

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?

Usage is implied through the block catalogue and the note that omitting 'block' returns a digest of all blocks (10 items each), which tells the agent how to choose between full-block and overview modes. There is no explicit when-to-use/when-not guidance or reference to the 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?

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds real value beyond them: result cap of 20, the fields returned, and the important policy that adult-only titles are never returned. Minor gap: no pagination/offset behavior is mentioned.

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 that front-load purpose, then returns, then next-step routing. Every clause carries information and nothing is redundant with 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?

With an output schema present, the description need not enumerate return fields in detail, and it still summarizes them. Combined with full schema coverage, annotated safety hints, and the adult-content exclusion policy, an agent has everything needed to call this 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 description coverage is 100%, so both `query` and `limit` are already documented with types, bounds, and defaults. The description adds example query strings ('cozy farming', 'soulslike') that illustrate the tag-matching intent, but nothing beyond the schema on the limit 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?

States a specific verb (Search/Find) and resource (Steam games) plus the query forms accepted (name or genre/tag words) with concrete examples. It is clearly distinct from fetch, which it calls out, but it gives no signal on how it differs from the sibling find_games or new_games, leaving one differentiation gap.

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 routes the agent: 'Use fetch with a result's id for the full record,' which tells the agent when this tool is sufficient and when to escalate. It does not explain when to prefer this over find_games or new_games, so the sibling-choice guidance is incomplete.

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