inject_input

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

Annotations only flag readOnly=false/idempotent=false/destructive=false; the description adds substantial extra context: events run in order, coordinates are CSS pixels from the canvas top-left matching capture_runtime framing, the return value { dispatched }, and the PointerEvent + MouseEvent/TouchEvent dispatch duality that lets both engine pointer sources and legacy pc.Mouse/pc.TouchDevice receive events.

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?

Purpose and the launch_start prerequisite are front-loaded, and the follow-up observation guidance (capture_runtime / read_runtime_logs) is well placed. It is on the longer side, but nearly every clause conveys actionable information with no redundancy.

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?

Although there is no output schema, the description states the return shape ({ dispatched }) and the full before/during/after workflow (launch_start → inject → observe via capture_runtime/logs/scene query), which is complete for a complex runtime-input tool.

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 already 100%, so the baseline is 3, but the description adds cross-cutting meaning beyond the schema: the coordinate reference frame is tied to capture_runtime's framing and the event list is explained as an ordered sequence with named patterns (holdMs for duration, down→move→up for drags).

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 (dispatch/inject input) and resource (keyboard/mouse/touch events to the RUNNING Launch instance) with concrete example interactions ("press W to move", "click a button"). It is clearly distinguishable from siblings like modify_entities or launch_start.

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?

Explicitly requires launch_start first, gives an explicit 'When NOT to use' clause routing to modify_entities and warning against use before launch, and enumerates concrete usage patterns (key hold, click, drag sequence, touch tap). Nothing is left to inference.

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