Skip to main content
Glama
wkoverfield

Quilt

by wkoverfield
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Quilt

CI npm downloads license

Quilt is a command-line tool that tracks which agent wrote which lines in a shared Git checkout, so multiple AI coding agents can work in one repo at once and each commits only its own changes.

It captures every edit at the tool boundary, keeps a per-line record of who wrote what, and reconstructs each agent's own changes at commit time. Git stays the source of truth. Quilt never calls an LLM or spawns agents, and its state lives in a .quilt/ sidecar you can delete without touching your repo.

Two agents editing one file, plain git vs Quilt. Without Quilt (left), the first agent's commit absorbs the other's work and the history credits one author. With Quilt (right), each change is committed by the agent that made it.

npm install -g @quilt-dev/cli
quilt setup     # capture hooks wired; claim enforcement via Claude hooks or MCP

The problem

You want your agents in ONE checkout: one node_modules, one build, one dev server, one environment to keep working, not a worktree per agent, each with its own install and its own drift. But on a shared checkout, plain git bites even when agents work on completely different things: the first git commit -am sweeps everyone else's uncommitted files into one blob, codegen and lockfile churn get credited to whoever committed last, and two agents occasionally do land on the same line, where one silently overwrites the other. None of that requires agents to be working on the same task. It's just what a shared checkout does by default.

Quilt makes the shared checkout safe. Every agent commits exactly its own lines and nothing else: disjoint work stays disjoint all the way into history, with no ceremony. And when two agents genuinely want the same code, that becomes a coordinated handoff instead of a silent loss. It holds as you add agents.

./examples/fleet.sh runs seven agents against one checkout. The two endings:

WITHOUT quilt   1 commit for 7 agents — six got "nothing to commit", their
                work swept into the first agent's blob. a7 silently
                overwrote a1's change to getUser. a1's work is gone.

WITH quilt      6 clean commits, one per agent, each exactly its own lines.
                a7's write into a1's claimed function was denied before any
                bytes changed, with a1's stated intent in the denial.

Related MCP server: LockRe

When two agents want the same file

Fanning out on disjoint files is the easy case. The real test is contention. A denied claim isn't a dead end. It carries the holder's stated intent and when their lease lapses:

$ QUILT_ACTOR=builder-flows quilt claim deals.js flows.js --intent "wire flows to deals"
  ✗ denied  deals.js (held by builder-friction)
      builder-friction is: friction pass: rename + archive flags
      their claim lapses 2026-07-04T22:12:05Z unless renewed
  ✓ claimed flows.js

So the blocked agent builds its granted files while it waits, re-claims after the holder's commit auto-releases, and layers its change on top of the landed one. Two clean commits, both changes in the file, nothing lost. ./examples/contention.sh runs the whole sequence on the real machinery.

What it does

  • One shared checkout. Model humans, agents, and bots as actors editing one working tree, no worktree per agent.

  • Line-level attribution. commit --mine commits only your lines, even when they share a hunk with another actor's.

  • Symbol-level claims. Reserve utils.js#formatPrice, not the whole file, so agents editing different functions never contend. Ten languages via tree-sitter; whole-file claims for the rest.

  • Collision prevention. A write into code another agent has claimed is denied, with the holder's stated intent, before any bytes change.

  • Push-awareness. Claim a symbol that depends on a function another actor is changing, and Quilt warns you at claim time.

  • Detect and preserve. If one actor overwrites another's uncommitted lines, Quilt snapshots the victim's version so nothing is silently lost.

Every commit Quilt produces is an ordinary Git commit. It trusts Git and never rewrites it, and all state lives locally under .quilt/. No account, no daemon.

Quickstart

quilt setup      # wire Quilt into the repo (capture hooks + optional MCP tools)
quilt doctor     # confirm it's wired and capture is flowing

That's it. Agents are named automatically: each Claude Code session or MCP connection gets its own id, so parallel agents are told apart with no setup.

4 terminals, one repo

The whole flow, from a git repo to four agents working at once:

cd your-repo
quilt setup          # once, ~5 seconds
claude               # terminal 1
claude               # terminal 2
claude               # terminal 3
claude               # terminal 4

Start sessions from a directory that holds several repos? Run quilt setup there instead: it wires the workspace root and every repo inside, and each edit is captured into the repo its file belongs to.

Nothing else. No QUILT_ACTOR, no per-terminal ceremony, nothing to approve: the capture hooks attribute every edit to its session automatically. Watch it live with quilt fleet, and when a session's work is ready, ask it to run quilt commit --mine -m "...". Each commit contains exactly that session's lines, even where two sessions touched the same file. (Claude Code will also offer to enable the optional quilt MCP server for the project; approving it adds the claim/prevention tools, but the hooks protect you either way.)

Watch the fleet

quilt ui opens the same picture in your browser, live: who wrote what (per-actor line counts per file), active claims, who's blocked on whom, and anything that needs a human. Local-only (127.0.0.1), read-only, one command.

The quilt ui dashboard: an escalated collision at the top under "Needs you", actor cards with their claims, a who-wrote-what table with per-actor line counts, and blocked/queued actors.

Prefer the terminal? quilt fleet --watch is the same view as text.

Set an explicit id when you want one that is stable across sessions:

QUILT_ACTOR=auth-agent claude    # this agent's edits are attributed to auth-agent

Then each agent commits only its own lines:

quilt status                     # who owns what
quilt preview --mine             # exact patch that would be committed
quilt commit --mine -m "fix auth redirect"
quilt provenance HEAD            # actor, session, files, hunks, tree

Quilt writes that provenance into the Git commit itself, so it survives normal pushes and fresh clones. Prompt correlation stays local in quilt ui; it is not published into Git history.

In a shared shell, make the committer explicit (quilt --as auth-agent commit --mine ...). Quilt refuses a checkout-global session identity when the dirty tree shows another actor. If a deploy provider requires a recognized Git email, set one once while keeping actor names distinct:

quilt config author.email you@example.com

quilt fleet shows the whole picture: every actor, their claims, and anything that needs a human. See docs/reference.md for the full command list.

Why not worktrees?

A worktree per agent is the usual answer, and for fully independent tasks it works. But every worktree is another environment to build (another install, another build cache, another dev server) and isolation just moves the collision to merge time. Those costs grow with the number of agents; the whole point of a shared checkout is paying for the environment once.

Run fewer agents

Worktree per agent

Quilt

Parallelism

capped low

high

high

Setup per agent

none

full install/build/env × N

none (one checkout)

See each other's in-flight work

n/a

no

yes

Collisions

avoided by hand

surface at merge

prevented, or surfaced live

Clean per-agent commits

n/a

after a merge

yes

Worktrees isolate; they don't coordinate. When agents work the same code at the same time, you usually want them to see each other and account for each other as they go. That is what Quilt does. The two aren't mutually exclusive: worktrees for independent, long-running work, Quilt for agents in the same code at once.

Using it with agents

quilt setup wires the capture hooks and a shared MCP server. On Claude Code the hooks let agents use the built-in Edit and Write tools normally while Quilt records each change's author and blocks a write into code another agent holds, with no protocol for the agent to follow and no setup: each session is named automatically, or carries its own QUILT_ACTOR for a stable id. For other runtimes, the same capture and prevention is available as MCP tools, with each connection named automatically the same way.

See docs/orchestrators.md for Codex, Cursor, Aider, and the difference between process-per-agent and many-agents-in-one-process setups.

Docs

  • docs/orchestrators.md: running a fleet of agents.

  • docs/reference.md: the full command list, how attribution works, and the .quilt/ state layout.

  • bench/: the scenario ladder Quilt is tested against, run with and without Quilt on the same metrics.

Telemetry

One anonymous heartbeat per day: quilt version, OS, Node major, random local id. Nothing else unless you opt in at quilt setup, and never code, paths, repo or actor names. quilt telemetry off, QUILT_TELEMETRY=0, or DO_NOT_TRACK=1 silences everything. Details: docs/reference.md.

Contributing

Contributions are welcome. See CONTRIBUTING.md.

License

MIT

Available Tools

12 tools
claimA

Reserve files BEFORE you edit them — a claim placed before editing is also what BINDS your external edits to your actor id, so claim whole files first as the default. Use a bare path for a whole file, a trailing slash for a whole directory (e.g. convex/_generated/ — right for codegen output), or path#symbol (e.g. utils.js#formatPrice) to reserve one function so others can edit other parts of the same file in parallel (a symbol that does not exist in the file is denied with a suggestion, since it would bind nothing). Pass a short intent (the why) so an actor you block can resolve the collision from it. A denied target is held by another actor — its holderIntent tells you what they're doing, so reconcile from that instead of just waiting.

ParametersJSON Schema
NameRequiredDescriptionDefault
waitNoseconds to BLOCK waiting for holder-denied targets to free up (holder releases, commits, or their lease lapses) instead of polling yourself. Returns as soon as everything grants. Capped at 120 per call — re-call to keep waiting. Denials that waiting can't fix (bad path, missing symbol) return immediately.
actorNoactor id to act as. Auto-derived per connection when omitted (from the client name, e.g. cursor-3fa2), so naming is optional for a single agent. Pass an explicit id (your role/task name) when several subagents share one server — they have no ambient identity to tell them apart — or when you want a stable id across runs.
pathsYes
queueNoASYNC alternative to wait: if denied by a holder, register interest and return immediately — you are AUTO-GRANTED the target when it frees. Do NOT block. Keep working; the grant appears in get_status as `grantedWhileWaiting`. Best when you have other work to do meanwhile.
intentNoa short why for this claim, e.g. the ticket/task
creatingNoallow symbol claims for symbols you are ABOUT TO ADD to an existing file (they bind at write time). Without it, a symbol missing from the file is denied.

TDQS

A4.6/5.0
Behavior5/5

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

Given no annotations, the description fully discloses behavioral traits: how claims bind edits, denial behavior (holder intent), wait/queue mechanisms, and symbol creation rules. No contradictions.

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?

The description is relatively long but each sentence adds essential information. It is front-loaded with the core purpose. Slight verbosity could be structured more concisely, but overall effective.

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?

With 6 parameters, no output schema, and complexity around path formats and collision handling, the description covers all necessary behavioral aspects, edge cases, and parameter usage thoroughly.

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 high (83%), but the description adds significant value beyond schema by explaining path formats, intent purpose, and behavior of wait/queue parameters. It clarifies the 'creating' flag's effect on symbol claims.

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 explicitly states the tool's purpose: 'Reserve files BEFORE you edit them' and explains that a claim binds external edits to the actor ID. It distinguishes from siblings by being the reservation/lock tool for editing.

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 description provides clear guidance on when to use the tool (before editing) and explains different path patterns for files, directories, and symbols. It does not explicitly exclude alternatives but the usage context is well defined.

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

commit_mineA

Commit ONLY your owned hunks as an ordinary git commit, leaving every other actor's changes untouched in the working tree. This is how each agent lands its own work in a shared checkout without sweeping up anyone else's. The committed files' claims auto-release, so no separate release call is needed. Preview it first with preview_mine.

ParametersJSON Schema
NameRequiredDescriptionDefault
actorNoactor id to act as. Auto-derived per connection when omitted (from the client name, e.g. cursor-3fa2), so naming is optional for a single agent. Pass an explicit id (your role/task name) when several subagents share one server — they have no ambient identity to tell them apart — or when you want a stable id across runs.
pathsNolimit the commit to these files (default: all your owned files) — a hard filter, so an unnamed orphan/leftover is never swept in
messageYesthe commit message
includeUnclaimedNoalso commit new/untracked files you authored but never claimed (default: false, so an unclaimed orphan is never swept into your commit while another actor is active)

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses key behaviors: commits only owned hunks, leaves other actors' changes untouched, and auto-releases claims. However, it does not mention failure modes (e.g., conflicts) or whether it pushes, but the main traits are well-covered.

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 four sentences, front-loaded with the core action, and every sentence adds value. It is efficient and avoids redundancy, earning a top score for conciseness.

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?

Given the complexity (4 parameters, no output schema, no annotations), the description provides sufficient context for the core use case. It explains the purpose, side effects (auto-release), and suggests a preview. It could mention edge cases or return values, but for a simple commit operation, it is adequate.

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 100%, with detailed descriptions for each parameter. The tool description does not add new per-parameter meaning beyond the schema, so it remains at the baseline. The description's context about 'owned hunks' and 'auto-release' provides general context but not parameter-specific guidance.

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 uses specific verbs and resources: 'Commit ONLY your owned hunks as an ordinary git commit'. It clearly distinguishes this tool from siblings like `preview_mine` (preview) and `claim` (claiming hunks), making its unique role evident.

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?

The description explicitly states when to use this tool (to land your own work in a shared checkout without affecting others' changes) and suggests previewing with `preview_mine`. It implicitly advises against using it when wanting to commit others' changes, providing clear context.

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

escalateA

Flag a collision you CANNOT reconcile (e.g. two opposed intents on the same line) for a human. Use this instead of forcing a change through when a denied claim's holderIntent conflicts with yours. It shows up under 'Needs you' until resolved.

ParametersJSON Schema
NameRequiredDescriptionDefault
actorNoactor id to act as. Auto-derived per connection when omitted (from the client name, e.g. cursor-3fa2), so naming is optional for a single agent. Pass an explicit id (your role/task name) when several subagents share one server — they have no ambient identity to tell them apart — or when you want a stable id across runs.
reasonNowhy it needs a human — name the opposed intents
targetYesthe clash, e.g. pool.js#maxConnections

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses that the flagged item shows up under 'Needs you' until resolved, adding useful behavioral context. While it doesn't detail side effects or permissions, the description sufficiently discloses the tool's impact for a flagging action.

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 two sentences plus a parenthetical example, with every sentence adding value. It front-loads the purpose clearly and avoids any filler, making it highly efficient for an AI agent to parse.

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?

Given the tool has 3 parameters, no output schema, and no annotations, the description provides adequate context: purpose, when to use, and a behavioral note. It could optionally mention what happens after escalation, but the 'Needs you' note covers the immediate outcome. It is complete enough for an agent to understand and use the tool correctly.

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%, so the baseline is 3. The tool's description does not add extra meaning beyond the schema's parameter descriptions. The example in the description provides context for 'reason' and 'target', but does not elaborate on syntax or usage beyond what the schema already provides.

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 clearly states the tool flags a collision that cannot be reconciled for a human, with a concrete example (two opposed intents on the same line). It distinguishes itself from forcing a change through, which differentiates it from sibling tools like 'commit_mine' or 'resolve'.

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?

The description explicitly tells when to use the tool (when reconciliation is impossible, specifically when a denied claim's holderIntent conflicts with yours) and what not to do (force a change through). This provides clear context for selecting this tool over alternatives.

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

get_conflictsA

Show overlapping/shared changes and collisions that were caught.

ParametersJSON Schema
NameRequiredDescriptionDefault
actorNoactor id to act as. Auto-derived per connection when omitted (from the client name, e.g. cursor-3fa2), so naming is optional for a single agent. Pass an explicit id (your role/task name) when several subagents share one server — they have no ambient identity to tell them apart — or when you want a stable id across runs.

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It states the tool shows conflicts, implying read-only behavior, but does not disclose other behavioral traits (e.g., side effects, required state, or what happens with missing actor). Minimal transparency.

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 a single sentence, concise and front-loaded. Every word contributes to the purpose without redundancy.

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?

Given the tool has one parameter, no output schema, and no annotations, the description adequately conveys the tool's purpose. It hints at output (conflicts that were caught) but lacks details on result format. Still, it is sufficiently complete for a simple tool.

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% for the single parameter 'actor', which is well-documented in the schema. The tool description adds no additional meaning beyond what the schema provides, so baseline score of 3 applies.

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 uses a specific verb ('Show') and resource ('collisions that were caught'), clearly indicating it displays conflicts. It distinguishes from siblings like 'get_my_changes' by focusing on overlapping changes rather than individual changes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies use when checking for conflicts but provides no explicit when-to-use, when-not-to-use, or alternatives among siblings like 'get_status' or 'get_my_changes'. The context is clear but guidance is absent.

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

get_my_changesA

List the changes YOU own in the working tree: the files and hunks attributed to your actor id, with per-file added/removed line counts. The 'what have I done so far' view, scoped to just you. Review your own work with it before committing — use get_status for who-owns-what across all actors, or preview_mine for the exact patch commit_mine would produce.

ParametersJSON Schema
NameRequiredDescriptionDefault
actorNoactor id to act as. Auto-derived per connection when omitted (from the client name, e.g. cursor-3fa2), so naming is optional for a single agent. Pass an explicit id (your role/task name) when several subagents share one server — they have no ambient identity to tell them apart — or when you want a stable id across runs.

TDQS

A4.5/5.0
Behavior4/5

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

No annotations provided, but description implies read-only behavior by describing listing of own changes. Lacks explicit mention of auth or side effects, but clear enough.

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?

Three sentences, front-loaded with main purpose, no redundancy. Every sentence adds value.

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?

Given simple tool with one optional param and no output schema, description covers behavior, output content, and alternatives completely.

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 covers parameter fully (100%). Description does not add extra meaning beyond schema, so baseline 3.

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 clearly states the tool lists changes owned by the user, with specifics (files, hunks, line counts). It distinguishes from siblings like get_status and preview_mine.

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?

Explicitly recommends use before committing and directs to alternatives: get_status for ownership across actors, preview_mine for patch preview.

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

get_statusA

Show who owns which working-tree changes, plus caught collisions and active claims. Call before editing and before committing.

ParametersJSON Schema
NameRequiredDescriptionDefault
actorNoactor id to act as. Auto-derived per connection when omitted (from the client name, e.g. cursor-3fa2), so naming is optional for a single agent. Pass an explicit id (your role/task name) when several subagents share one server — they have no ambient identity to tell them apart — or when you want a stable id across runs.

TDQS

A3.8/5.0
Behavior2/5

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

With no annotations, the description carries the full burden for behavioral disclosure. It only says 'Show', implying a read-only operation, but does not confirm no side effects, required permissions, or other behavioral traits.

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 concise sentences: the first states the purpose, the second gives usage context. No extraneous information, well front-loaded.

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 tool with one optional parameter and no output schema, the description provides enough context to decide when to use it. It mentions what is shown (ownership, collisions, claims), but does not describe the output format or structure, which could help in selecting the tool.

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 100%, and the description adds no additional meaning to the 'actor' parameter beyond what the schema already provides. Baseline score of 3 is 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?

The description clearly states the tool shows ownership of working-tree changes, collisions, and active claims, using specific verbs and a clear resource. It distinguishes from siblings like get_my_changes and get_conflicts by covering all three aspects.

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 description explicitly says to call before editing and before committing, providing clear when-to-use guidance. However, it does not specify when not to use or mention alternative tools for specific needs.

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

preview_mineA

Show the exact patch commit_mine would create right now: only your owned hunks as a unified diff, plus the files, whole-file additions, and added/removed line totals. A dry run, nothing is written. Review it before commit_mine to confirm you are committing your lines and nothing else.

ParametersJSON Schema
NameRequiredDescriptionDefault
actorNoactor id to act as. Auto-derived per connection when omitted (from the client name, e.g. cursor-3fa2), so naming is optional for a single agent. Pass an explicit id (your role/task name) when several subagents share one server — they have no ambient identity to tell them apart — or when you want a stable id across runs.
pathsNolimit to these files (default: all your owned files)
includeUnclaimedNoalso include new/untracked files you authored but never claimed (default: false, so an unclaimed orphan is left out while another actor is active)

TDQS

A4.5/5.0
Behavior5/5

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

No annotations exist, so the description fully bears the burden. It clearly states the tool is a dry run ('nothing is written') and describes the output content (unified diff, files, totals), leaving no ambiguity about side effects.

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 pithy sentences that front-load the primary purpose and immediately clarify it is a dry run. Every phrase earns its place.

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?

Given no output schema, the description compensates by explaining what the tool shows (diff, files, totals). It provides a complete picture for an agent to decide to invoke it.

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 detailed parameter descriptions. The tool description adds no extra semantic value beyond what the schema already provides, so baseline of 3 is 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?

The description clearly states the tool's purpose: 'Show the exact patch commit_mine would create right now' and is a dry run. It distinguishes from the sibling tool commit_mine by emphasizing it's a preview.

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?

Provides explicit usage guidance: 'Review it before commit_mine to confirm you are committing your lines and nothing else.' This tells the agent when to use it relative to its sibling.

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

quilt_editA

Edit a file through Quilt instead of your raw editor. Replaces the unique old_string with new_string and records WHO authored the change at the moment of the edit — so attribution is exact even when several agents share this checkout, with no claims or reconcile guesswork. Pass why (your ticket/task). Prefer this over a plain file edit when coordinating a fleet.

ParametersJSON Schema
NameRequiredDescriptionDefault
whyNoa short why for this edit, e.g. the ticket/task
pathYesfile path (repo-relative or absolute; stored repo-relative)
actorNoactor id to act as. Auto-derived per connection when omitted (from the client name, e.g. cursor-3fa2), so naming is optional for a single agent. Pass an explicit id (your role/task name) when several subagents share one server — they have no ambient identity to tell them apart — or when you want a stable id across runs.
new_stringYesthe replacement text
old_stringYesthe exact text to replace (must be unique in the file)

TDQS

A4/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that the tool replaces a unique old_string, records authorship exactly, and avoids attribution guesswork. It does not mention error handling or side effects but adds behavioral context beyond the schema.

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 very concise: one paragraph with no redundant words. It front-loads the purpose, explains the key benefit, and gives a usage tip. Every sentence 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?

While parameters are well-covered and behavior is described, the description lacks context about the overall workflow (e.g., whether the edit is staged or auto-committed) and does not mention return values. For a file edit tool in a versioned system, more context would be helpful.

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 input schema has 100% description coverage. The description adds context for 'why' (ticket/task) and 'actor' (optional but useful for subagents), enhancing meaning beyond the schema definitions.

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?

The description clearly states it edits a file by replacing an old string with a new one, and records authorship. It distinguishes from a raw editor but not explicitly from sibling tool 'quilt_write'. The verb 'edit' and resource 'file through Quilt' are specific.

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 description advises to pass 'why' and prefer this over plain file edit when coordinating a fleet. It gives a clear usage context but does not explicitly mention when not to use or compare to alternatives like 'quilt_write'.

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

quilt_writeA

Create or overwrite a whole file through Quilt instead of your raw editor, recording YOU as the author of its contents at write time, so attribution is exact even when several agents share this checkout, with no claims or reconcile guesswork. Use this for new files; use quilt_edit to change part of an existing one. Pass why (your ticket/task). If another agent holds this path, the write is denied with their intent so you can reconcile instead of clobbering.

ParametersJSON Schema
NameRequiredDescriptionDefault
whyNoa short why for this write, e.g. the ticket/task
pathYesfile path (repo-relative or absolute; stored repo-relative)
actorNoactor id to act as. Auto-derived per connection when omitted (from the client name, e.g. cursor-3fa2), so naming is optional for a single agent. Pass an explicit id (your role/task name) when several subagents share one server — they have no ambient identity to tell them apart — or when you want a stable id across runs.
contentYesfull file contents to write

TDQS

A4.6/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It clearly explains authorship recording, attribution exactness, and the denial behavior when another agent holds the path. However, it lacks details on atomicity or error handling.

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 a single paragraph of four sentences, each adding essential information. It front-loads the main purpose, then provides usage guidelines and behavioral notes. No redundant or superfluous text.

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 tool without output schema, the description adequately covers how to use, when to use, and what behavioral guarantees exist. It does not describe return values or error messages, but given the simplicity, it is mostly complete.

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 100%, but the description adds value by explaining the 'why' parameter's purpose ('your ticket/task') and the 'actor' parameter's auto-derivation logic and when to use an explicit ID. The 'path' and 'content' are sufficiently described.

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 uses specific verbs ('Create or overwrite') and clearly identifies the resource ('a whole file through Quilt'). It distinguishes from sibling tool 'quilt_edit' by stating the scope ('new files' vs 'change part of an existing one').

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?

Explicitly states when to use this tool ('Use this for new files') and when to use the sibling ('use quilt_edit to change part of an existing one'). Also provides guidance on passing 'why' and warns about concurrent access denial.

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

releaseA

Release your claims on the given paths. Omit paths to release ALL of yours; an empty array releases none.

ParametersJSON Schema
NameRequiredDescriptionDefault
actorNoactor id to act as. Auto-derived per connection when omitted (from the client name, e.g. cursor-3fa2), so naming is optional for a single agent. Pass an explicit id (your role/task name) when several subagents share one server — they have no ambient identity to tell them apart — or when you want a stable id across runs.
pathsNo

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It explains behavior for different path inputs but does not disclose side effects, reversibility, or permissions needed. Some behavioral context is given (release all vs. none), but it is limited.

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 two sentences, front-loads the purpose, and provides parameter usage without any fluff. Every word contributes value.

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?

Given the tool's simplicity (2 parameters, no output schema, no nesting), the description covers the essential actions and parameter behavior. It could elaborate on what 'release' means for the system state, but it is adequate for correct invocation.

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 50% (actor described, paths not). The description adds meaning to the 'paths' parameter: it explains what omitting vs. empty array means. The 'actor' parameter is already well-described in the schema.

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?

The description states the action 'release your claims' on given paths, providing a clear verb and resource. It distinguishes from siblings like 'claim' by implication, but does not explicitly contrast with other 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 Guidelines4/5

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

The description gives explicit guidance on parameter usage: omit paths to release all, empty array releases none. However, it lacks guidance on when not to use the tool or alternatives.

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

resolveA

Mark a collision as sewn/handled after you reconciled it — closes its 'Needs you' flag and records the audit trail. Use after you've merged or adapted so the work accounts for both intents.

ParametersJSON Schema
NameRequiredDescriptionDefault
noteNowhat you did to reconcile it
actorNoactor id to act as. Auto-derived per connection when omitted (from the client name, e.g. cursor-3fa2), so naming is optional for a single agent. Pass an explicit id (your role/task name) when several subagents share one server — they have no ambient identity to tell them apart — or when you want a stable id across runs.
targetYesthe clash that was resolved, e.g. pool.js#maxConnections
takeFromNoalso transfer dirty operations from this stale/conflicting actor to the resolver

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses key behaviors: marks collision, closes flag, records audit trail. However, it does not mention reversibility, required permissions, or side effects beyond the stated actions. Given the lack of annotations, more detail would be beneficial, but the description is adequate.

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 two sentences, front-loaded with the primary action and outcome. Every sentence adds value without redundancy. It is well-structured and efficient.

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?

Given no output schema and no annotations, the description covers the core purpose, usage context, and basic parameters. It lacks details on return value or confirmation, but for a straightforward state-modifying tool, it is reasonably complete.

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%, so baseline is 3. The description does not add additional meaning beyond what the schema provides for the parameters. It mentions the use context but does not elaborate on parameter formats or constraints.

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 clearly states the verb ('Mark') and resource ('collision'), and explicitly describes the outcome ('closes its 'Needs you' flag and records the audit trail'). It distinguishes itself from siblings like 'claim' or 'escalate' by specifying the post-reconciliation use case.

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 description explicitly says 'Use after you've merged or adapted', providing clear context for when to invoke. It does not explicitly state when not to use or list alternatives, but the sibling list and context imply alternatives (e.g., 'escalate' for unresolved collisions).

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

start_sessionA

Register an actor and start a session in this repo, pinning this server to that identity. Optional: if several agents share one server, skip this and pass actor on each call instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNo
typeNo
actorYesactor id, e.g. auth-agent
emailNo

TDQS

A4/5.0
Behavior3/5

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

Discloses registration, session start, and pinning. With no annotations, more details on side effects (e.g., session duration, idempotency) would improve transparency. Not misleading but lacks depth.

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 sentences: first states purpose, second gives usage guidance. No wasted words, front-loaded with key information.

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?

Covers main purpose and usage but lacks parameter descriptions and return value hints. Adequate for a simple tool, but incomplete due to missing parameter semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only the 'actor' parameter is contextualized in the description; 'name', 'type', and 'email' are left unexplained. Schema coverage is low (25%), but description only partially compensates.

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 clearly states the tool registers an actor and starts a session, pinning the server to that identity. It distinguishes from siblings like claim or commit by being about session management, not content operations.

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?

Explicitly provides when to use (register actor and start session) and when not to (if sharing server, skip and pass actor per call). Offers an alternative approach.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool update
    • Changedresolve1 field changed
      • addedInput schema / properties / takeFrom
        Added value: +{
+  "description": "also transfer dirty operations from this stale/conflicting actor to the resolver",
+  "type": "string"
+}
  2. 3 tool updatesv0.4.4
    • Changedcommit_mine2 fields changed
      • addedInput schema / properties / includeUnclaimed / description
        Added value: +"also commit new/untracked files you authored but never claimed (default: false, so an unclaimed orphan is never swept into your commit while another actor is active)"
      • addedInput schema / properties / message / description
        Added value: +"the commit message"
    • Changedpreview_mine1 field changed
      • addedInput schema / properties / includeUnclaimed / description
        Added value: +"also include new/untracked files you authored but never claimed (default: false, so an unclaimed orphan is left out while another actor is active)"
    • Changedquilt_write2 fields changed
      • changedInput schema / properties / content / description
        Previous value: -"full file contents"New value: +"full file contents to write"
      • addedInput schema / properties / why / description
        Added value: +"a short why for this write, e.g. the ticket/task"
  3. 12 tool updatesv0.4.3
    • First observedclaim
    • First observedcommit_mine
    • First observedescalate
    • First observedget_conflicts
    • First observedget_my_changes
    • First observedget_status
    • First observedpreview_mine
    • First observedquilt_edit
    • First observedquilt_write
    • First observedrelease
    • First observedresolve
    • First observedstart_session
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a distinct purpose: claiming, committing, editing, status queries, conflict resolution. No two tools serve overlapping functions.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (e.g., get_status, commit_mine, quilt_edit). The naming convention is uniform.

Tool Count5/5

With 12 tools, the set is well-scoped for collaborative file editing: covering session management, claims, edits, commits, and conflict handling without bloat.

Completeness4/5

The tool surface covers the core workflow (claim, edit, commit, release, resolve). Minor gaps exist (e.g., no undo/revert tool), but the essential operations are present.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • agentsync

    jarmstrong158
    A
    license
    A
    quality
    B
    maintenance
    Enables multiple AI agents to collaborate on the same git repository by coordinating work via a shared claims branch, detecting file conflicts before they happen.
    9
    PolyForm Noncommercial 1.0.0

  • LockRe

    crsxmd
    A
    license
    Not graded
    quality
    B
    maintenance
    LockRe prevents file edit collisions among multiple AI agents and allows surgical revert of each agent's changes line-by-line, without affecting others' work.
    1
    MIT
  • cafecito by Cafecitohq

    cafecitoofficial

    Cafecitohq
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to coordinate on a shared repository using commutativity-proven parallel landing and regenerative merge, avoiding rebase conflicts through symbol-level leases.
    Apache 2.0

  • befall

    esenbora
    A
    license
    Not graded
    quality
    B
    maintenance
    Multiplayer coordination for AI coding agents: Claude Code, Codex CLI and Cursor share one room per repository. An agent claims a path glob before it edits and a conflicting claim is refused at claim time, so collisions are prevented rather than resolved at merge. Metadata only — source code and diffs never leave the machine.
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wkoverfield/quilt'

If you have feedback or need assistance with the MCP directory API, please join our Discord server