Server Quality Checklist

Tool Scores

• rebase_continueB
  3.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the refusal condition and explains why auto_resolve is off, which is useful. Yet it does not mention other side effects or error scenarios beyond the refusal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and to the point, with the purpose in the first sentence and additional details in separate short paragraphs. No filler words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has an output schema (not shown), so return details are covered. The description gives a constraint and auto_resolve context, but relies on knowledge of rebase_start and does not explain prerequisites or the phrase 'the other way a marker reaches a commit'.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It explains auto_resolve's behavior and default rationale, but does not mention the `repo` parameter at all, leaving it unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool carries on with a rebase and reports the next stopping point. This distinguishes it from siblings like rebase_start and rebase_status, though it does not explicitly name them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides a refusal condition (while any path is unmerged) and references rebase_start for auto_resolve behavior, giving some context. However, it does not explicitly name alternative tools or state when to choose this over them.

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

• rebase_finishA
  3.7/5.0
  Behavior4/5

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

  With no annotations, the description carries full responsibility for disclosing behavior. It explains that the tool compares the branch's change to its base rather than the resulting tree, scans for conflict markers, and explicitly states that the backup tag is kept either way. This is substantive behavioral transparency, though it omits details about the 'allow_change' parameter.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately verbose but front-loaded with the main purpose. Each paragraph adds a distinct point about the tool's behavior (what must stay the same, conflict marker scanning, backup tag retention). It is well-structured, though some phrasing could be tightened.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the core behavior and logic well, but it lacks operational details such as what 'tidy up' concretely does and what 'allow_change' influences. While an output schema is present, the missing parameter semantics and side-effect information make the description incomplete for a correct and safe invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not mention the 'repo' or 'allow_change' parameters at all. Most critically, it fails to explain what allowing change does, which is essential for correct invocation. The description adds no parameter-level meaning, leaving the agent to guess.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's specific function: 'Check the finished rebase against the tip it started from, and tidy up.' This distinguishes it from sibling tools like rebase_start, rebase_continue, or rebase_status, which have different roles in the rebase workflow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies clear usage context—'Check the finished rebase'—indicating it is used after a rebase has completed. It provides guidance on what to compare (the change to the base) but does not explicitly name alternative tools or exclusions, which keeps it from a 5.

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

• rebase_skipA
  3.8/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states the tool drops the commit being replayed, carries on the rebase, and refuses when no commit is in question (at break/exec failure). It also explains the rationale (avoiding manual git half-driving). It doesn't describe side effects like working tree state, but the core mutation is clearly disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the central action, followed by a concise rationale and a clear refusal condition. Every sentence earns its place; no filler. It is appropriately sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description thoroughly covers the tool's behavior, when to use it, and refusal conditions. However, it completely omits parameter semantics (repo, auto_resolve), which is a significant gap given the 0% schema coverage and the presence of an output schema that doesn't compensate. The behavioral context is good, but the missing parameter information reduces overall completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not mention the 'repo' or 'auto_resolve' parameters at all. The description adds no meaning beyond the bare names in the schema. 'auto_resolve' is particularly ambiguous and undocumented, leaving the agent without necessary information to set parameters correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear, specific verb+resource: 'Drop the commit being replayed and carry on.' It precisely identifies the tool's function (skipping the current commit during a rebase) and distinguishes it from sibling tools like rebase_resolve (which resolves conflicts) and rebase_continue (which continues after resolution).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit use cases: when a commit's change is already in the base under a different sha, or when a conflict resolves to 'the branch already says this.' It also states when the tool is refused (at a break or failing exec), giving clear context. However, it does not explicitly name alternative tools, instead referring to running git by hand, which slightly weakens the alternative guidance.

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

• rebase_abortA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description must fully disclose behavior. It explains the primary effect (abandonment) and one consequence (restoring moved-aside items), which is helpful. However, it omits details such as error conditions when no rebase is active, whether the action is reversible, or any side effects on uncommitted changes, leaving gaps in behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no filler. It states the action and its direct consequence in an efficient manner, fully earning its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  An output schema exists, but the description is minimal for a destructive operation. It does not indicate prerequisites (e.g., that a rebase must be in progress), potential errors, or what happens to the repository state beyond putting things back. The presence of sibling rebase tools suggests a richer context, but the description itself provides limited completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has one optional parameter 'repo' with a default of '.', and the description does not mention it. With 0% schema description coverage, the description should compensate, but the parameter is self-explanatory from its name and default. The schema already conveys its meaning, so the description adds no additional value, making a mid-range score appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'abandon' with the resource 'rebase' and adds effect context ('put back anything that was moved aside'). This clearly distinguishes it from siblings like rebase_continue or rebase_skip, which imply progression rather than cancellation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Abandon the rebase' clearly implies the tool is for canceling an in-progress rebase, providing clear context for when to use it. However, it does not explicitly mention when not to use it or name alternatives, so it stops short of a full 5.

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

• rebase_statusA
  4.1/5.0
  Behavior3/5

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

  With no annotations provided, the description is the only source of behavioral information. It adds useful context about the `head_is_replaying_commit` field and how it differs from git's output, but it does not state whether the tool is read-only, what happens if no rebase is in progress, or any error conditions. This leaves safety and edge-case behavior undisclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, each earning its place: the first states the purpose, the second provides usage guidance and a key output detail. No redundancy with the schema or titles.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one parameter) and has an output schema, so the description doesn't need to explain return values. It gives enough context for a developer to understand when to invoke it, but it omits edge-case behavior (e.g., no rebase in progress). Overall, it is a solid but not exhaustive description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description mentions `repo` only as part of the resource phrase ('in `repo`') and does not explain the parameter's meaning, format, or default behavior. Schema description coverage is 0%, and the description does not compensate by clarifying that repo defaults to '.' (current directory) or what values are acceptable.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Report' with the resource 'the rebase in repo', clearly distinguishing this status tool from sibling action tools like rebase_amend, rebase_continue, and rebase_resolve. The first sentence unambiguously states what it does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells the agent to 'Call this before amending, continuing or resolving,' naming the exact sibling actions that should follow. It also explains the unique value of the `head_is_replaying_commit` field, which helps the agent know when to use the tool.

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

• rebase_preflightA
  4.3/5.0
  Behavior5/5

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

  Without any annotations, the description carries full responsibility. It explicitly states the tool is non-destructive ('without starting it or changing anything') and details the categories of reports it produces, providing strong transparency beyond what structured fields offer.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no filler. The first sentence is a clear summary; the second packs several report categories into a list. Slightly dense but each clause is informative and earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, non-destructive behavior, and the kinds of output, which is sufficient for a preflight check with an output schema present. It does not explicitly mention the 'repo' parameter or usage timing, but the overall context is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It indirectly explains 'todo' and 'base' through the report list, but does not explicitly define the parameters, their types, or defaults. 'repo' is entirely omitted. This is partial but not complete compensation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Check') and resource ('what a rebase would do'), and explicitly states that it does not start or change anything. This clearly distinguishes it from sibling tools like rebase_start and rebase_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the preflight intent clear (check before rebase, without mutating), which implies when to use it. However, it does not explicitly name alternative tools or state when not to use it, though the sibling list provides context.

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

• rebase_amendA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral burden. It discloses the refusal condition, the dangerous silent-folding scenario at conflicted stops, and the stage_tracked semantics (tracked-only, no untracked files). This goes well beyond the input schema and is highly informative.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: main action first, then a critical refusal context, then a parameter explanation. Every sentence adds value and there is no redundant or vague wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the core behavior, refusal reasons, and the most nuanced parameter. It lacks explicit setup for repo/message, but these are relatively self-evident from names and defaults. An output schema exists, so return values are not needed in the description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It thoroughly explains stage_tracked, but repo and message are not discussed. The names and defaults offer some hints, but explicit explanation of what 'message' does (e.g., new commit message) and what 'repo' refers to would be needed for full compensation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Amend the commit this rebase has just applied,' a specific verb+resource that clearly distinguishes this from sibling tools like rebase_skip, rebase_abort, or rebase_status. It also clarifies the exact scope of operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives strong when-not guidance: 'Refused at every other kind of stop' and explains the conflicted-stop caveat. However, it does not explicitly name alternative tools (e.g., 'use rebase_continue after resolving'), leaving the agent to infer alternatives from sibling names.

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

• rebase_resolveA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• rebase_todoA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the behavioral disclosure burden. It explicitly explains the safety check: replacements that drop commits are refused unless force, exec lines are counted, and dropping all execs silently disables the check—which is called out. This goes well beyond basic expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than a simple one-line statement, but each paragraph earns its place: the lead sentence defines the tool, the second gives motivational context, and the third is a critical safety explanation. The structure is logical and front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (read/replace with nuanced safety rules), the description covers the important behavior and usage context. An output schema exists, so return values are not needed in the description. The dual read/write behavior is implicitly tied to the 'todo' parameter default of null, which is inferable from the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description explains the role of 'todo' (replacement list) and 'force' (allows dropping commits) but does not mention the 'repo' parameter. With 0% schema description coverage, this partial explanation compensates only somewhat. The format of the todo array entries is also left vague, though examples like 'exec' hint at it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Read the steps a running rebase has left, or replace them,' which clearly states the tool's dual function on the rebase todo list. This is a specific verb+resource combination and distinguishes it from siblings like rebase_status (which reports status) and rebase_amend (which edits commits).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'Worth having because' paragraph gives a concrete scenario ('a fixup turns out to depend on a commit scheduled after it') and explains the value of editing the todo list instead of aborting and restarting. It also implicitly advises when to use force. However, it does not explicitly name alternative tools or state when not to use this tool.

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

• rebase_startA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavioral details: tags the current tip for checking, moves aside untracked files, runs check_command after every commit, and explains auto_resolve composition behavior. This far exceeds minimal safety/effect disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tightly structured with four paragraphs, each focused on a distinct aspect: main behavior, autosquash, check_command, and auto_resolve. Every sentence adds value and is front-loaded with the primary action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the operation's complexity well, including failure modes and flag interactions. It doesn't explain the return format, but an output schema exists to fill that gap. The missing 'repo' parameter is a minor gap in an otherwise complete description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must explain parameters. It covers base, force, autosquash, check_command, and auto_resolve in depth. However, 'repo' is not explained at all, and 'todo' is only mentioned as incompatible with autosquash, lacking format or usage details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Begin a rebase onto `base`, and report where it stops.' This clearly identifies it as the starting operation in the rebase lifecycle and distinguishes it from siblings like rebase_continue or rebase_abort.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear usage conditions: refuses unsafe operations unless force, cannot combine autosquash with todo, and auto_resolve is off by default with guidance on when to use it. Does not explicitly name sibling alternatives for when not to use this tool, but the context is strong.

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

• rebase_conflictsA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden. It discloses precise behavioral details: per-region two diffs from common base, omission of regions where only one side changed, and parameter effects. This goes well beyond the tool name and provides a clear mental model of the output.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured paragraph that front-loads the purpose, then covers output structure, exclusions, and parameter tuning. Every sentence contributes meaningful information without repetition or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is complete for a diagnostic tool: it explains what it does, how to interpret results, what is intentionally omitted, and how to vary parameters. The output schema likely covers exact return structure, and the only minor omission of `repo` is acceptable given its default and self-explanatory type.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 0% description coverage, so the description must compensate. It fully explains both `context` ('how many unchanged lines to show around each change') and `include_full_sides` ('for the three whole texts'), including when to increase them, effectively replacing missing schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Report each conflict as what the two sides did, rather than as markers.' It distinguishes itself from generic conflict listing by explaining the two-diff structure and what is intentionally omitted, making it stand out among sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context on how to use the tool, including when to adjust `context` and `include_full_sides`. However, it does not explicitly name alternatives or state when to prefer this over `rebase_status` or `rebase_resolve`, so usage is implied rather than explicitly contrasted with siblings.

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