epic_get_game_details

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

No annotations are provided, so the description bears the full burden of disclosing behavior. It mentions the default DLC exclusion and the 50-item limit, but it does not state whether the call is read-only, whether authentication is required, whether results are cached, or what errors or edge cases might occur. For a no-annotation tool, this is a meaningful transparency 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 short and front-loaded: a one-sentence purpose followed by compact parameter definitions. Every sentence earns its place, and there is no redundant repetition of the tool name or 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?

For a simple two-parameter detail lookup, the description covers the core invocation needs: what to pass, where the identifiers come from, and a key option's default behavior. However, with no output schema and no annotations, it omits return structure, authentication dependencies, and any relation to auth or cache-refresh siblings, leaving some practical context unresolved.

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 has no descriptions, so the Args section fully compensates. It explains that app_names are Epic app_name identifiers from epic_list_games and cap at 50 per call, and it clarifies include_dlcs as a way to include DLC entries while excluded by default. This adds substantial meaning beyond the raw schema types.

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 resource (specific Epic games) and the content returned (title, description, developer, install info), which makes the tool's purpose obvious. However, it relies on the tool name for the verb 'get' and does not explicitly contrast itself with sibling detail tools like igdb_get_game_details or steam_get_game_details, so it stops short of full differentiation.

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 Args section says app_names come 'from epic_list_games', which implies a two-step workflow: list games first, then fetch details. It also explains the include_dlcs default. But it gives no explicit guidance on when to choose this tool over the other get-details siblings, no exclusions, and no mention of prerequisites such as authentication.

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