Send a low-level virtual input event

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

Annotations already flag destructiveHint=true and non-idempotent, and the description adds substantial context on top: VirtualInputManager is preferred with executor fallbacks, calls are wrapped in newcclosure when available, and unsupported executor APIs return a structured error instead of a false success. It also names the phase, cost, idempotency class, and verification path.

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 safety warning is front-loaded ('WRITES LIVE GAME STATE') and most sentences carry distinct information. The inline Signature block largely restates the enum and parameter list already present at 100% schema coverage, which is the one redundant element keeping this from a 5.

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 19-parameter mutation tool with no output schema, the description covers what it writes, how it behaves on failure (structured error, inspect tool-schema), the preferred implementation path, required approvals, and how to verify. Nothing an agent needs to invoke it correctly is missing.

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 100%, so the baseline is 3, but the description adds real mapping value by binding each action to its parameters (keyDown/keyUp/keyPress use Enum.KeyCode, mouseMove supports absolute or relative, touch sends Begin/Change/End, gamepadButton/gamepadAxis target a gamepad). This clarifies which fields apply to which action, which the flat schema does not.

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 keyboard, mouse, touch, or gamepad input into the active Roblox client') and immediately frames itself as 'the broad low-level input surface', distinguishing it from press-key and the higher-level GUI input siblings. An agent can place it precisely 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?

Explicitly routes the simple case to press-key ('Use press-key for the simpler keyboard-only case') and lists prerequisites (active-client, explicit-mutation-approval) and a verification step (assert-state). It does not mention other plausible alternatives such as click-button or type-text-box for GUI targeting, so it falls just short of full when/when-not coverage.

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