compose-bridge

Overview Schema Source Related Servers Discussions Admin

reject_change

Destructive

Revert a single unwanted hunk in a file while keeping other changes intact; use it to remove one specific change without discarding the rest of the file's edits.

Instructions

Reverts a single granular change (hunk) in a file while keeping other changes intact.

What it does: Reverts only the specified hunk back to its original baseline on disk.
When to use: When one specific change in a file is unwanted, but other changes in the file should be kept.
Parameters:
  - file_path: relative path to project root
  - change_id: hunk ID (e.g. "h1", "h2") or line number
Returns:
  JSON string with operation result and remaining changes.

Input Schema

Name	Required	Description	Default
`change_id`	Yes
`file_path`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is known; the description adds real value by scoping the destruction to only the specified hunk and by stating it restores the baseline on disk. It doesn't mention whether the action can be undone or that the file must currently be in a modified state, which would be the remaining useful context.

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?

Labeled sections (What it does / When to use / Parameters / Returns) make it scannable and the core action is front-loaded in the first sentence. The headers are slightly heavy for a two-parameter tool but every line carries information.

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 destructive single-hunk mutation with two required params and an output schema, the definition covers purpose, selection criteria, parameter formats, and result shape. The only gap is recovery/undo behavior and any precondition about the file being modified, which matters given the destructive hint.

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%, so the description carries the full burden, and it does compensate well: file_path is anchored to "relative path to project root" and change_id accepts either a hunk ID with concrete examples ("h1", "h2") or a line number. The ambiguity of how a bare line number resolves to a hunk is left unexplained, keeping it from 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 states a specific verb and resource ("Reverts a single granular change (hunk) in a file") plus a scope qualifier ("while keeping other changes intact"). That granularity implicitly but clearly distinguishes it from sibling tools like reject_file_changes and reject_all_files, which operate at file or batch level.

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 "When to use" line gives a clear selection condition: one unwanted change while keeping others in the same file. It stops short of naming the alternative (reject_file_changes) explicitly for the case where all changes should go, so it falls shy of a 5.

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