set_input_action

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

Annotations already flag destructiveHint=true and openWorldHint=true, and the description adds real value on top: 'complete binding list' discloses that all existing bindings are overwritten, and 'Preserves deadzone when omitted' describes a subtle merge behavior not visible anywhere else. dryRun and expectedHash are named as safety mechanisms but never explained, which keeps this below a 5.

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?

Three tight sentences with the create-or-replace contract front-loaded, followed by the two behavioral caveats an agent most needs. No filler, though the trailing feature list ('Supports key, mouse button and joypad bindings, dryRun and expectedHash') is enumeration rather than explanation.

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?

An output schema exists so return values need no explanation, but the tool is a destructive mutation with a nested 12-property events array at 0% schema coverage. The description never explains the event shape, what expectedHash guards against, or what dryRun returns, leaving meaningful gaps for a tool this complex.

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% across six parameters, so the description must carry the load. It names the binding kinds and clarifies deadzone's omission behavior, but dryRun, expectedHash, and projectPath are only listed, not defined, and the twelve-field event object (keycode vs key, axisValue, device, modifiers) is entirely unaddressed.

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 — 'Create or replace a configured action and its complete binding list' — which makes the upsert semantics explicit and separates it from get_input_actions and remove_input_action. It stops short of naming those siblings directly, so an agent must infer the boundary rather than read it.

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?

The 'create or replace' phrasing implies when this tool applies, but there is no explicit guidance on when to prefer it over get_input_actions (read) or remove_input_action (delete), and no stated prerequisites. Usage is inferable rather than instructed.

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