Skip to main content
Glama
Sign In
naw103

Foremerge

by naw103
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Accept a validated ChangeSet

accept_changeset

Formalize acceptance of a validated ChangeSet to enable other agents to build on the changes. This action completes the verification phase, marking the ChangeSet as approved and ready for integration.

Instructions

Accept a ChangeSet as done so other agents may build on it. Use this after run_verification passes; use record_commit later, once the work has actually landed on the target branch. Foremerge re-checks every gate before accepting: the worktree must be clean and unchanged since publication, verification must have passed (unless the repository's policy is advisory and nothing was verified), no HIGH conflict on the intent may be OPEN or COORDINATING (resolve_conflict clears an agreed one, and discard_work dismisses the conflicts of work you drop), and every intent in the ChangeSet's dependencies must already be accepted, with its accepted commit, or once committed its recorded integration commit, in this commit's history. On success it marks the ChangeSet and intent ACCEPTED, pins the commit as accepted_commit, writes refs/foremerge/accepted/<changeset_id>, and returns the updated ChangeSet. A failed gate returns an error naming it (CHECK_FAILED, BLOCKING_CONFLICT, UNSATISFIED_DEPENDENCY, STALE_CHANGESET, INVALID_TRANSITION) and changes nothing. Overriding a gate is an operator action on the CLI or HTTP API and is refused over MCP, so ask a human when a gate should be bypassed.

Input Schema

NameRequiredDescriptionDefault
git_refNoOptional commit to accept. Defaults to the ref recorded at publication, then the worktree HEAD. Whatever it names must resolve to the current worktree HEAD.
changeset_idYesThe ChangeSet to accept (chg_...), as returned by publish_changeset.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.3
    • addedInput schema / properties / changeset_id / description
      Added value: +"The ChangeSet to accept (chg_...), as returned by publish_changeset."
    • addedInput schema / properties / git_ref / description
      Added value: +"Optional commit to accept. Defaults to the ref recorded at publication, then the worktree HEAD. Whatever it names must resolve to the current worktree HEAD."
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say it is a non-destructive, non-idempotent write with no override; the description adds substantial context beyond that: it enumerates every gate re-checked, the exact failure error codes, that a failed gate changes nothing, and the state written on success (ACCEPTED status, accepted_commit pin, refs/foremerge/accepted/...). It also discloses that gate overrides are refused over MCP and must go to a human, which is critical behavior an agent could not infer.

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?

Front-loaded with purpose and the when-to-use rule before the gate detail, and nearly every clause carries load-bearing information (gate list, error codes, side effects). The gate enumeration is dense and slightly overlong, but not wasteful.

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?

No output schema exists, yet the description states what is returned (the updated ChangeSet) along with state mutations and ref writes. Combined with the explicit failure modes and MCP override restriction, an agent has everything needed to call it correctly and interpret the result.

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 100%, with git_ref's defaulting and HEAD-resolution rules documented in the schema itself, so the description does not need to repeat them. The description adds only indirect meaning (the worktree must be clean and unchanged), leaving the baseline 3 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?

States a specific verb and resource ('Accept a ChangeSet as done') plus the downstream consequence ('so other agents may build on it'). It explicitly contrasts with the sibling record_commit, so an agent can distinguish the two without opening either schema.

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?

Gives an explicit ordering rule: use this after run_verification passes, and use record_commit later once work has landed. It also names the sibling tools that clear blocking conditions (resolve_conflict, discard_work), so the agent knows how to unblock a failed accept.

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

Deploy Server

Other Tools