set_game_mode_player_state_class

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true) by disclosing the persistence semantics: Blueprint packages are dirtied but not saved, native-class values survive only until the editor closes, and the value is read back from the CDO. This is exactly the behavioral nuance an agent needs before invoking a mutation.

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 the specific action and target in the first clause, then adds the two behavioral caveats, then the return shape. Every sentence earns its place 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?

No output schema exists, and the description compensates by spelling out the exact return object fields. Combined with the persistence caveats and full schema coverage, an agent has everything needed to call and interpret the result.

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 three parameters including the class-path precedence rule. The description adds only the read-back-from-CDO detail, which concerns the return value rather than parameter meaning; baseline 3 is appropriate.

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: it 'sets' the AGameModeBase::PlayerStateClass UPROPERTY on the GameMode's CDO. This cleanly distinguishes it from siblings like set_game_mode_hud_class and set_game_mode_game_state_class, which target different UPROPERTYs on the same CDO.

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?

Provides clear usage context by explaining what happens after the call: a Blueprint GameMode is marked dirty and must be persisted via save_asset, while a native class's value is not persistable. It doesn't explicitly name when to prefer it over a sibling, but the follow-up action and persistence conditions give an agent enough to act correctly.

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