get_game_instance_info

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the remaining burden is on the odd runtime semantics — and the description delivers the non-obvious one: exists=false with empty strings at rest is the NORMAL answer, not an error. It also discloses the return shape. It does not discuss cost or timing, but for a local editor read that is minor.

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-loads what is read, then the critical 'not an error' caveat, then the sibling routing, then the return contract. Every sentence carries information; the trailing Returns block is justified because no output schema exists.

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?

No output schema and no parameters, so the description must carry the full contract — and it does, spelling out every returned field plus the world_type enum. An agent can call this and interpret the result correctly without anything else.

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?

Zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description correctly adds no param detail because none exists.

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 and resource (reads the live UGameInstance plus engine world contexts) and enumerates exactly what comes back — name, class, object path, world_name, and the world_type enum values. It also distinguishes itself from the sibling get_engine_info by saying which one answers the GameInstance question.

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?

Explicit when-to-use ('answer "is a game session up, and which GameInstance class did it pick?"') and explicit alternative routing ('Pick this over get_engine_info when you care about the GameInstance itself'). Both the selection condition and the sibling trade-off are named, nothing left to inference.

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