Skip to main content
Glama

merge_unmerge

Undo a confirmed merge by restoring the pre-merge nodes from its receipt snapshot; provide the matching confirm-unmerge token.

Instructions

Undo a confirmed merge from its receipt snapshot, restoring the pre-merge nodes exactly. Requires confirm-unmerge-<merge_id>.

Input Schema

NameRequiredDescriptionDefault
merge_idYes
confirm_tokenYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

No annotations, so the description carries full behavioral burden. It discloses the token-gated auth flow and the destructive scope ('restoring the pre-merge nodes exactly'), which is real added context, but says nothing about reversibility of the undo itself, permissions/ownership requirements, or what happens if the merge_id is invalid or already unmerged.

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?

Two short sentences, zero filler, with the outcome stated first and the prerequisite second. Every clause earns 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?

For a 2-parameter mutation tool with no annotations and no output schema, the description covers purpose and the token prerequisite but leaves failure modes, idempotency, and return behavior unaddressed. Adequate to call it, not complete enough to call it confidently.

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 coverage is 0%, so description compensation matters. It documents the confirm_token format precisely via 'confirm-unmerge-<merge_id>', which is genuinely useful, but merge_id is left unexplained (presumably a receipt/merge identifier) and neither parameter notes format, source, or constraints.

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?

States a specific verb and resource: 'Undo a confirmed merge from its receipt snapshot, restoring the pre-merge nodes exactly.' That clearly separates it from merge_propose and merge_execute, though it never names a sibling explicitly, so the differentiation is implicit from the context of the merge family.

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 prerequisite 'Requires confirm-unmerge-<merge_id>' tells the agent this is the post-merge reversal path and that a token must first be obtained. It gives clear context for when to invoke, but no explicit when-not-to-use guidance (e.g. what to do if the merge is not yet confirmed or already unmerged).

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