Skip to main content
Glama
naw103

Foremerge

by naw103
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Accept a validated ChangeSet

accept_changeset

Accept a changeset as complete after verification passes, unlocking other agents to build on it.

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 in this commit's history. On success it marks the ChangeSet and intent ACCEPTED, pins the commit as accepted_commit, writes refs/foremerge/accepted/, 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

TableJSON 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.9/5.0
Behavior5/5

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

Despite annotations only stating non-read-only/non-idempotent, the description goes far beyond them by disclosing that Foremerge re-checks every gate, that a failed gate changes nothing and returns named error codes, that success writes refs/foremerge/accepted/<changeset_id>, and that overriding gates via MCP is refused. This is comprehensively transparent about side effects and failure behavior.

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 dense but every sentence carries load-bearing information: purpose, sequencing, gate criteria, side effects, error behavior, and override policy. The most important usage guidance is front-loaded, and the gate details are grouped logically.

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?

For a state-changing tool with no output schema, the description fully explains preconditions, gate checks, success effects, failure modes, error identifiers, and the boundary of what MCP can do. An agent has enough to decide whether to call it and what to expect.

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?

The schema already covers both parameters fully, so the baseline is 3. The description adds meaningful semantics for git_ref by explaining its fallback resolution order (publication ref, then worktree HEAD) and the constraint that it must resolve to the current worktree HEAD, which is not in the schema.

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 ('Accept a ChangeSet as done') and immediately names the higher-level purpose ('so other agents may build on it'). It also contrasts with record_commit, which is the later step once work lands, so an agent can distinguish this from 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 Guidelines5/5

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

It explicitly says when to use the tool ('after run_verification passes'), when not to use it yet ('use record_commit later'), and how to handle conflicts via resolve_conflict and discard_work. It also tells the agent that gate overrides are refused over MCP and a human should be consulted, which is actionable routing guidance.

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