compose-bridge

Overview Schema Source Related Servers Discussions Admin

approve_change

DestructiveIdempotent

Approves a single granular change (hunk) in a file, incorporating it into the baseline backup while leaving other changes pending for further review or rejection.

Instructions

Approves a single granular change (hunk) in a file.

What it does: Incorporates the specific change into the file's baseline backup, leaving other changes pending.
When to use: When one specific change in a file is approved, but other changes need further inspection or rejection.
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.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description's extra detail is genuinely additive: it explains that the hunk is merged into the file's baseline backup while other changes remain pending. That state-change disclosure is exactly what an agent needs before a destructive call; only permissions/irreversibility detail is missing.

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?

Labeled sections (What it does / When to use / Parameters / Returns) with the core action front-loaded in the first line. Every sentence carries distinct information; nothing is padding.

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 2-param destructive mutation, the description covers action, scope, triggering condition, parameter meaning, and return shape, which is ample. Since an output schema exists, the Returns line is somewhat redundant but harmless; missing detail on failure modes or permission requirements keeps it short of 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 description coverage is 0%, so the description must carry the load and it does: file_path is clarified as relative to project root, and change_id is clarified as a hunk ID like "h1"/"h2" or a line number. The format examples add meaning the schema lacks, though edge cases (line number vs hunk ID precedence) are unstated.

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?

States a specific verb and resource ("Approves a single granular change (hunk) in a file") and the scope word "single" plus "hunk" cleanly separates it from approve_file_changes, approve_all_files, and reject_change. An agent can pick the right sibling without opening any schema.

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 an explicit condition: one specific change approved while other changes need inspection or rejection. It implies but does not name the alternatives (reject_change, approve_file_changes), so the routing guidance is clear but not fully explicit.

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