Set dance keybind

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

Annotations only say readOnlyHint=false and openWorldHint=false, leaving the real behavior unexplained. The description fills that gap with the crucial detail that the binding is written to MCP state and that the tool returns a Luau hint snippet rather than applying anything in-game — an agent would otherwise assume the keybind takes effect immediately.

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?

A single front-loaded sentence with zero filler: the action, the key domain, the write target, and the return value all appear before any clause the agent must read twice.

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?

With no output schema, the description helpfully states that the return is a Luau hint snippet, and both required parameters are covered by the schema. What remains thin is failure behavior (unknown key, unmatched dance name), which is not addressed.

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 100%: the key list and the dance-acceptance forms (substring, exact name, InternalName, 1-based index) are already documented in the schema. The description repeats the key slot list without adding syntax, precedence, or error behavior, so baseline 3 is correct.

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 pairs a specific verb ("Bind") with a specific resource ("a dance to a key slot") and names the exact key domain, so it is instantly distinguishable from reanim_list_dance_keybinds. It also flags a non-obvious effect ("in MCP state") that separates it from reanim_switch_dance, though it never names those siblings explicitly.

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?

There is no explicit when-to-use guidance, no prerequisites, and no alternatives named. An agent calling this alongside reanim_list_dance_keybinds or reanim_switch_dance gets no instruction on which to prefer or in what order.

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