Send a key to the running game

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

With no annotations, the description carries the full burden and does most of it well: it explains the frame-hold and re-assert mechanism, that the call blocks until the game has consumed all frames, that slow/headless frame rates or browser focus loss cannot swallow the input, and that the reply carries the measured frame rate and whether the player's cell changed. It does not warn that a key press can trigger irreversible in-game actions (menu confirmations, selections), which is the main behavioral risk for a live-input tool.

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 the core action and key table, and every sentence carries information. The third sentence is dense and slightly overloaded (frame rate, focus loss, reply contents in one breath), but nothing is padding.

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 no annotations and no output schema, the description covers purpose, alternative routing, dependency, blocking semantics and reply contents, which is nearly everything an agent needs. It is silent on failure modes such as the plugin being absent or no live session running.

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 67%; keyCode has no schema description, and the description compensates with a concrete mapping (Ok=13/32, Cancel=27, Shift=16, arrows 37-40). It also gives meaning to the frame-count behavior behind holdFrames and pulses, though it never names those parameters directly or reconciles them against the documented defaults.

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 ('Press a game key in the live game') and immediately differentiates from the sibling that could be confused with it by naming live_move and the condition that selects it. The parenthetical key-code table makes the exact resource concrete rather than generic.

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 says when to use it (advance dialogs or drive input) and when to use the alternative instead ('To walk somewhere, prefer live_move: one press is one step only if the player happens to be standing still when it lands'). It also states the prerequisite ('Needs the RMMZLiveBridge plugin, not Allow Eval'), which is exactly the kind of routing guidance an agent needs.

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