Routes OK or START taps and encoder steps to the app listening through the window manager; include delta only for encoder movement.
Route an OK or START tap, or an encoder step, to an app listening through the WM. Supply delta only for the encoder.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| delta | No |
Changes observed during successful MCP inspections.
v0.10.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It explains the dispatch model (the event is routed to an app that is listening through the WM) but says nothing about the outcome when no app is listening, whether the call blocks, whether it errors, or what it returns.
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 short sentences with no waste, and the primary action is front-loaded ahead of the conditional delta rule. Slightly clipped to the point that it reads as internal shorthand ("the WM").
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 2-parameter input-injection tool with no output schema and no annotations, the description covers the action and the conditional parameter but omits the failure/no-listener case and any observable result. Adequate to attempt a correct call, incomplete for predicting its effect.
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 0%, so the description must compensate: it does useful work by implying delta is conditional on key="encoder" (delta is optional in the schema, key is required). However, it never explains what a delta unit means (steps? direction sign?), leaving the -10..10 bound and the semantics of magnitude uninterpreted.
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 uses a specific verb ("Route") plus the resource (input events: OK/START tap, encoder step) and names the destination (an app listening through the WM), so an agent can distinguish this from the display-oriented bar_*/busybar_* siblings. It stops short of 5 because "WM" is unexplained jargon and the phrase "through the WM" is the only thing tying the tool to a target.
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 gives a conditional rule for delta ("Supply delta only for the encoder"), which is real usage guidance, but it never states when to call this versus e.g. busybar_switch_app or busybar_show_message, nor what happens if no app is listening. Usage is implied by the input-event framing rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.