simulate_input

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

Annotations already declare readOnly=false, destructive=false and openWorld=true, so the safety profile is mostly covered. The description usefully adds that effects are confined to the live debug session and explains the release semantics of pressed:false, but says nothing about the sessionId prerequisite, whether injected input persists, or how it interacts with the running game state.

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?

Two compact sentences with the scope constraint front-loaded and the release hint second. No filler, though it is arguably too terse for a 9-parameter tool.

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?

With 9 parameters, 11% schema coverage, no output schema and no detailed annotations, the description should explain how the parameters combine per kind and confirm the sessionId requirement. It does neither, leaving an agent to guess the invocation shape for any kind other than a simple key release.

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 11% (only sessionId is documented), so the description carries most of the burden and mostly fails: it clarifies pressed:false only. The meaning of kind enum values, x/y versus action versus keycode/button, and strength (0-1) are left entirely to bare schema types.

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 (send input events to the live debug session) and scopes it with 'only', which separates it from the config-oriented set_input_action/set_input_action siblings. It stops short of naming an alternative or spelling out which input kinds map to which parameters.

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?

'Live debug session only' implies the prerequisite that a debug session must already be running, and the pressed:false sentence gives one concrete usage recipe. There is no explicit statement of when not to use it or which sibling to prefer for configuring input actions instead of injecting them.

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