steam_get_dlc

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

Annotations already declare readOnlyHint=true, so the description is not required to restate that. However, it adds only 'optionally with live prices and sale status,' which is a capability but not a behavioral disclosure. It omits notable behaviors such as the one store lookup per DLC during enrichment, potential slowness, or rate-limit implications. With annotations covering safety, the description contributes minimal additional 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, efficient sentence with no wasted words and the verb front-loaded. It is concise and easy to parse. However, it is arguably too terse for a tool with this many options; a bit more structure (e.g., mentioning enrichment or response formats) would not make it 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 six parameters, including enrichment, country code, and response format, the description is extremely sparse. There is no output schema, so the description should at least hint at what the returned data looks like, but it only says 'List DLC.' It omits prerequisites (base game appid), performance caveats (enrichment is concurrent), and the meaning of options like on_sale_only. This is far from complete for an agent to call 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 0%, meaning the tool description does not mention any parameters. While the schema itself provides descriptions for appid, limit, enrich, and on_sale_only, the description fails to compensate for the missing parameter semantics (country_code, response_format) or to reinforce the schema's details. Since coverage from the description is zero and the tool has six parameters, the description must add value but 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 clearly states the action ('List') and the resource ('a game's DLC'), and hints at optional features (live prices, sale status). It is distinct from siblings like steam_get_app_details or steam_get_package_details because 'DLC' is a specific resource, but it does not explicitly name an alternative or contrast itself, so it falls 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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites (e.g., needing a base game appid), or when to prefer a different tool like steam_get_app_details. The agent must infer usage from the name and schema alone.

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