mc_move

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

No annotations are supplied, so the description carries the full burden of behavioral disclosure. It does add the valuable tick-to-seconds mapping (20 ticks = 1 second), but it omits whether the call blocks for the duration, whether the player halts afterward, how conflicting direction flags resolve, or what happens if an obstacle blocks movement.

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 no filler; the duration semantics — the least obvious part of the call — is placed immediately after the action verb. Nothing needs trimming.

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 an eight-parameter game-control tool with no annotations and no output schema, the description is thin. It says nothing about blocking behavior, direction reference frame (world vs. look direction), or when to prefer mc_goto for longer traversal, all of which an agent needs to call this correctly.

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 only 13%, with just 'ticks' documented, so the description must compensate for seven undocumented boolean flags. The 'ticks' unit conversion is genuinely useful added meaning, but the direction/sprint/sneak flags get no explanation of mutual exclusivity, defaults, or how they combine during the hold.

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 ('Hold') plus the resource ('movement keys') and defines the duration unit, so an agent knows it drives locomotion for a timed interval. It does not distinguish itself from siblings like mc_key (single key press) or mc_goto (pathfinding navigation), leaving that boundary implicit.

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?

Usage is only implied by the phrase 'hold movement keys' — an agent can infer this is for continuous movement rather than a discrete tap. There is no explicit when-to-use, no when-not, and no pointer to mc_goto or mc_key for cases where a fixed hold duration or single keypress is wrong.

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