get_save_game_info

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

Annotations already establish readOnly/idempotent/non-destructive, but the description adds substantive context beyond them: a missing slot is not an error, exists returns false with no path or size, and file_size only appears when the file is on disk. It also grounds the tool in the underlying UGameplayStatics::DoesSaveGameExist behavior.

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?

Front-loaded with the core action and scope, followed by behavioral nuance, sibling routing, and a compact return shape. Every sentence carries distinct information with no filler.

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?

There is no output schema, so the description supplies the return contract itself ({slot_name, user_index, exists, save_path?, file_size?}) along with the conditional presence rules. Nothing an agent needs to call or interpret this read-only tool 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%, so both parameters are already documented, and the description adds little parameter-level detail (user_index is not mentioned, and slot_name syntax is not elaborated). The path template concerns the output, not the input. Baseline 3 is appropriate when the schema carries the load.

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 (check) and resource (one save slot), and explicitly differentiates from three siblings by scope: get_save_game_slot_info adds modification time, does_save_game_exist returns only the flag, list_save_games returns every slot. An agent can route without opening any schema.

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?

Names the alternatives and the exact condition that selects each one (modification time needed, flag only, all slots). Explicit when-to-use routing with no inference required.

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