mc_goto

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

With no annotations, the description carries the load and does it well: it declares the async contract (returns immediately), the required polling pattern, the failure mode ('no path'), and hard limits (client-side pathfinding, loaded chunks, 128 blocks). It omits whether an in-flight walk is cancelled or superseded by another action, which is a meaningful gap for a long-running autonomous operation.

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 short sentences, front-loaded with the action, then the async contract, then the failure mode. Every clause carries distinct information with no restatement of the name.

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 async tool with no output schema, the description covers the immediate return, how to track progress, and the unreachable-target case, which is what an agent needs to call it correctly. Missing only edge behavior such as interruption by other actions or what happens when the target chunk unloads mid-path.

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 100%, so x/y/z and sprint are already documented, including the 'feet block' nuance on y. The description only adds the 128-block reachability constraint on the target coordinates, so the baseline of 3 applies.

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 ("walk to world coordinates") plus the mechanism ("simple client-side pathfinding"), which distinguishes it from a raw movement primitive like mc_move and routes follow-up to mc_goto_status. An agent can tell what this does without opening the schema.

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?

Gives clear operating context: loaded chunks only, 128-block cap, and the explicit instruction to poll mc_goto_status because the call returns immediately. It never contrasts itself with mc_move or mentions mc_goto_stop for cancellation, so alternatives are only implied by the sibling set.

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