game_manage

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

With no annotations present, the description carries the full burden of behavioral disclosure. It reveals important traits: 'A present but malformed position is rejected rather than silently falling back to the cursor,' 'Action-based input is focus-independent, so it works on a backgrounded game window,' and 'Cannot run inside batch_execute.' It also describes replies, state reads, and the effect of each op on the running game.

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?

The description is long but appropriately structured: a one-line summary, a prerequisite note, then a consistent bulleted list of ops with syntax and parameter details. The canonical call shape paragraph adds useful invocation context without redundancy. Every sentence provides valuable information; nothing is wasted.

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?

For a tool with nine sub-operations, a minimal schema, and no annotations, this description is remarkably complete. It covers prerequisites, parameter semantics, timing and ordering constraints, return metadata (e.g., 'Includes path, type, text where present'), and usage exclusions. An agent can confidently select the right op and invoke it correctly without additional information.

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?

The input schema only defines an `op` enum and a generic `params` object with additionalProperties true, offering zero parameter descriptions. The description compensates fully by detailing every parameter for each operation, including types, defaults, and constraints such as get_scene_tree's root_path behavior, input_mouse's position format and malformed-value handling, and input_sequence's step ordering requirement.

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?

The description opens with 'Runtime game inspection and input simulation,' which is a specific verb+resource statement that clearly distinguishes this tool from sibling tools like editor_manage or scene_manage. It then enumerates nine distinct operations with clear names and one-line purposes, leaving no ambiguity about what the tool does.

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?

It explicitly states the prerequisite: 'Start the project first with project_run and poll editor_state until game_capture_ready=true.' It also provides usage guidance within the tool, e.g., 'Use this instead of separate input_action calls whenever timing matters' and 'Cannot run inside batch_execute,' which tells the agent when to use this tool and when not to.

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