rebase_resolve

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

With no annotations, the description must carry the full transparency burden. It does well by explaining the staging behavior, the three routes, and the safety check that rejects content with conflict markers, including the rationale. It omits details about workspace-side effects or error handling, but the key behavioral traits are disclosed.

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 efficiently structured, front-loading the core purpose and then using a clear enumerated list for the three usage modes. Every sentence contributes value—cost ordering, the 'both' meaning, and the safety rule. No fluff, and the length is justified by the tool's complexity.

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 a tool with four parameters, no annotations, and an output schema, the description is nearly complete. It covers the main modes and the conflict-marker constraint. It doesn't mention path/repo specifics or how to identify conflicted paths, but sibling tools (rebase_conflicts) fill that gap. Minor omissions keep it from a 5.

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 0%, and the description compensates by explaining 'take' values ('both', 'branch', 'replaying'), the 'content' parameter, and the no-arguments case. However, the `repo` parameter is not mentioned at all. The explanation adds substantial meaning beyond the raw schema, but the repo gap prevents a 5.

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 opens with a specific verb-resource pair: 'Stage the resolved content for one conflicted path.' This clearly identifies the tool's unique role relative to siblings like rebase_conflicts, which lists conflicts, and rebase_status, which shows status. It distinguishes itself as the action of resolving and staging.

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 provides explicit usage guidance for the three modes ('take', 'no arguments', 'content') and even orders them by cost. It tells the reader when to use 'take' versus editing in place. It does not explicitly name alternative sibling tools (e.g., rebase_skip) for when resolution should be skipped, so it's not a perfect 5.

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