Game Manage

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

With no annotations, the description carries the full burden and does so: it discloses idempotency of resume, that next_frame reports verification and a focus handoff, the embed_signal vs direct_session split and the direct fallback's inability to sync the Game View suspend button, that mouse buttons stay held until released with motion carrying button_mask, that wheel steps are one-shot, and that action input is focus-independent.

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 purpose and prerequisite, then a scannable bullet-per-op list, with the canonical call shape at the end — good structure for a 13-op tool. A few passages, notably the Embedded Game View focus-handoff and embed_signal fallback details under next_frame, are implementation trivia that slow scanning without changing how most agents would call it.

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?

Given high complexity (13 ops), zero annotation coverage, and 0% schema description coverage, the description supplies prerequisites, per-op parameters, response hints for the trickiest op, and the invocation envelope. An output schema exists, so return-value explanation is correctly omitted rather than duplicated.

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 coverage is 0% (only op/params/session_id with no property descriptions), so the description must compensate entirely and does — it documents per-op parameters inline (depth, root_path, include_properties, include_hidden/include_disabled/max_depth, device/control/index/value, strength, settle_frames) plus accepted formats for position ({x,y} or [x,y]) and button names. It also flags a rejection behavior ('malformed position is rejected rather than silently falling back') that the schema cannot express.

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?

First sentence gives a specific verb+resource ('Runtime game inspection and input simulation') and immediately scopes it to the running game process via Godot's EngineDebugger, which distinguishes it from editor-side siblings like scene_get_hierarchy or node_get_properties. The 13 enumerated ops make the tool's surface fully legible without opening the 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?

States the prerequisite workflow explicitly ('Start the project first with project_run and poll editor_state until game_capture_ready=true'), names alternatives in two places ('Use this instead of separate input_action calls whenever timing matters'), and gives an exclusion ('Cannot run inside batch_execute'). An agent knows both when to use it and what would invalidate the call.

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