screenscraper_get_game_info

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns metadata and media assets, but it does not disclose important behaviors: whether it requires authentication/API key, rate limits, network dependency, whether it can fail when no match is found, or whether it performs a remote API call. For a tool that fetches external data, this is a significant 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 two sentences, front-loading the core purpose and then listing search methods and return types. It is efficient and free of fluff. It could be slightly more structured (e.g., separating search methods from return types), but it earns its place with no wasted words.

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 9 parameters, no required fields, no output schema, and no annotations, the description is not complete enough. An agent cannot tell which parameters are mutually exclusive, which are required for a successful lookup, or what the response structure looks like. The tool's complexity (multiple search modes, external API) demands more guidance than the description provides.

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 the schema already documents all 9 parameters. The description adds the high-level concept that parameters can be used as search methods (ID, name, checksums), which is useful. However, it doesn't clarify relationships between parameters (e.g., whether systemId is required for name searches, whether checksums are preferred over names, or how language affects output). Baseline 3 is appropriate since the schema does the heavy lifting.

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 tool's purpose: retrieving detailed information and media assets for a retro game from ScreenScraper.fr. It specifies multiple search methods (game ID, name, ROM checksums) and the types of metadata returned (screenshots, covers, wheels, videos). This distinguishes it from sibling tools like screenscraper_search_game (which likely only searches) and steam_* tools (which are for Steam, not retro games).

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 by listing search methods, but it does not explicitly state when to use this tool versus alternatives like screenscraper_search_game or game_get_full_profile. It doesn't provide conditions like 'use this when you have a ROM checksum' or 'use screenscraper_search_game when you only need a game ID'. The context is clear for a retro game lookup, but exclusions and alternative routing are absent.

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