Skip to main content
Glama

set_player_controller_class

DestructiveIdempotent

Set a GameMode's PlayerController class on its live instance or Blueprint defaults, then compile and save the GameMode to prevent PIE spawning the old class.

Instructions

Point the world's GameMode at a PlayerController class, writing the live GameMode instance if one exists and otherwise the defaults of the world's Blueprint GameMode (refused when the GameMode is a native class, or when the world has none: those defaults are process-wide and never saved). success is read back from the slot written. WARNING: It does NOT compile or save the GameMode Blueprint, so a later PIE can still instantiate the OLD class from the already-compiled BlueprintGeneratedClass (three reads can agree on the new class while PIE spawns the engine default). Always follow with compile_blueprint on the GameMode and then save_asset, and verify in PIE by the SPAWNED controller's full class path -- never by re-reading this slot.

Returns: { player_controller_class: string, game_mode_class: string, written_to: string ('live_game_mode' | 'game_mode_defaults'), success: bool (the written slot reads back the class; still not a PIE oracle) }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
player_controller_classYesClass name or full path (e.g. '/Game/MyGame/Core/BP_MyPlayerController.BP_MyPlayerController_C'); rejected if it is not a child of APlayerController.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Far exceeds what the annotations convey. It discloses the refusal conditions, that it does NOT compile or save the Blueprint, the stale-BlueprintGeneratedClass PIE hazard (three reads can agree while PIE spawns the old class), and that success is only a read-back of the written slot, not a PIE oracle. This is exactly the behavioral context an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, then the refusal conditions, then the warning, then the return shape. Every sentence is substantive, though heavy nested parentheses and a mid-sentence ALL-CAPS WARNING make it denser and harder to scan than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still enumerates the return fields (player_controller_class, game_mode_class, written_to with its two literal values, success) and clarifies that the boolean is not a PIE oracle. Combined with refusal cases and the required follow-up calls, an agent has everything needed to invoke and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter already documents accepted forms (class name or full path) and the child-of-APlayerController validation. The description adds no parameter-level syntax or format detail beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource: it points the world's GameMode at a PlayerController class, and it specifies exactly which slot gets written (the live GameMode instance, or the world Blueprint GameMode's defaults otherwise). It is unambiguous and clearly distinguishable from the sibling setters like set_game_mode_override or set_game_mode_default_pawn.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives strong conditional guidance (live instance vs defaults; refused for native GameMode classes or worlds with no GameMode because those defaults are process-wide) and prescribes a follow-up workflow: compile_blueprint, then save_asset, then verify in PIE. It does not explicitly name sibling tools as alternatives, which keeps it from a 5.

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

Deploy Server

Other Tools