go_to_marker

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

The annotations only provide destructiveHint=false, and the description correctly describes a non-destructive cursor move without contradicting that. It adds the useful detail that the edit cursor is what moves, but does not disclose whether playback is affected or how invalid indices are handled. For a simple navigation tool, this is adequate but not rich.

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?

The description is a single, front-loaded sentence with no filler. Every word earns its place, and nothing important could be removed without losing meaning.

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?

The tool is simple, with one required integer parameter and no nested objects or output schema. However, a fully invocation-ready description should clarify marker_index semantics and point to get_markers as the source of valid indices. The current text conveys intent but leaves the exact contract under-specified.

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 needed to clarify marker_index semantics. It does not specify whether the index is zero-based or one-based, what the valid range is, or that the index should come from get_markers. The parameter name is self-descriptive at a surface level, but the actual calling contract remains ambiguous.

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 ('Move'), names the affected resource ('edit cursor'), and names the destination ('a marker'). This clearly distinguishes it from siblings like go_to_region, set_cursor_position, and get_markers.

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 description gives no guidance about when to use this tool over alternatives, notably the sibling go_to_region. It also does not mention that marker indices should be obtained from get_markers or address any when-not-to-use conditions.

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