Coordination server for parallel coding agents: claims, contracts, notices, and memory notes.
Quick Install
Automated & IDE SetupCopy the AI prompt to install this server into Claude Code, Cursor, or another agent — or use 1-click editor setup below.
One-click editor setup isn’t available for this listing yet — we don’t have a confirmed install command, and we’d rather show nothing than point your editor at the wrong package or host. Follow the project’s own setup instructions, linked above.
Manual Client & Custom JSON ConfigExpand JSON â–¾
No confirmed setup config for this listing yet. We only publish a config block when the install details come from the project itself — its README, its docs, or a verified owner. We haven’t found those for Tirith, and we’d rather show nothing than a guess you’d paste into your client. Follow the project’s own setup instructions for the current steps.
Documentation Overview
Tirith
Coordination server for parallel coding agents.
Claims, a task board, interface contracts, change notices, a decisions log,
path-scoped memory notes, and agent messages, over MCP.
Run five or ten coding agents on one repository and they edit the same files, rename things others depend on, and build both sides of an interface to different shapes. Tirith is a small daemon they all talk to: an agent claims files before editing, gets the notices, contracts, decisions, and notes for those files back with the claim, and publishes the shape of an interface before either side implements it.
It works with anything that speaks MCP, over stdio or HTTP: Claude Code, Cursor, Codex, LangGraph, CrewAI, or a plain script.
It also remembers. Agents leave notes scoped to repository paths, so what one agent learned about a file reaches the next agent that claims it. Tirith stores no conversation history and no embeddings.
Status: v1 shipped. Every primitive, the CLI, persistence, and the dashboard are built and tested, against the definition in ADR-0013; tool schemas follow semantic versioning.
Install
macOS and Linux:
Windows (PowerShell):
With cargo (the package is tirith-mcp, the binary is tirith):
Already installed? tirith update replaces the binary in place with the
latest release. Prebuilt binaries for macOS, Linux, and Windows on x86_64
and ARM64 are on the releases page;
every option is in docs/1-about/05-installation.md.
Listed in the MCP Registry:
mcp-name: io.github.eabz/tirith.
Quick start
Register tirith stdio with your client, the same way as any other stdio
MCP server. It starts the repository's daemon the first time a session
needs it, replaces a daemon of another version, and proxies to it after
that; nothing has to be started by hand.
| Client | Setup |
|---|---|
| Claude Code | claude mcp add tirith -- tirith stdio |
| Cursor | .cursor/mcp.json: { "mcpServers": { "tirith": { "command": "tirith", "args": ["stdio"] } } } |
| Codex | codex mcp add tirith -- tirith stdio |
| LangGraph, CrewAI, curl | connect over HTTP, see docs/2-examples/02-client-setup.md |
The daemon serves MCP at http://127.0.0.1:7477/mcp and a live dashboard
at http://127.0.0.1:7477/. State is written to .tirith/ in your
repository: contracts, notices, decisions, and memory notes are meant to
be committed; .tirith/runtime/ (claims, tasks, messages) is gitignored
by a .gitignore Tirith writes itself.
Every agent passes a stable agent name with each call. That is the only
convention it has to follow.
What it does
| Primitive | Tools | Purpose |
|---|---|---|
| Claims | claim, release, renew, claims_list | Lease files or directories before editing. Overlaps are refused with the owner, reason, and expiry, or waited out server-side with wait_secs. Leases expire if the agent dies, and the agent is told on its next call. |
| Task board | task_create, task_pull, task_update, task_list | Tasks with priority, owner, and dependencies. Agents pull the next unblocked task, skipping tasks another agent holds, and can wait server-side for one with wait_secs; a task whose owner goes silent returns to the board. |
| Contracts | contract_publish, contract_get, contract_list | Interface shapes published and versioned before implementation. A new version notifies its consumers automatically. |
| Change notices | notice_publish, notice_list | "Renamed X to Y, these paths are affected." Dependents get them in the brief that comes back with a claim, once each. |
| Decisions log | decision_record, decision_list | Settled choices with rationale, so nothing is decided twice. |
| Memory notes | memory_write, memory_read, memory_search, memory_delete | Lessons, traps, and handoffs scoped to repository paths. Committed Markdown, searchable, and delivered to whoever claims the paths a note is about. |
| Messages | message_send, message_list | Short notes between agents, delivered on the recipient's next call, so any MCP client can take part. Runtime only. |
| Status | status | Counts, persistence and load problems; verbose adds who holds what. |
| Guide | guide | What Tirith is for, the working loop, and which tool a situation calls for; topic narrows it to one primitive. |
Twenty-three tools, each with a description of every parameter, MCP
annotations, and an output schema. Every result is JSON with a status
field, lists are paged, and any result may carry lost (a lease that
ended) or inbox (messages waiting). The full reference, the single source of truth for
tool schemas, is docs/1-about/04-primitives.md.
Example
Two agents, one directory. The second is refused with enough information to decide what to do next:
A note left for whoever edits a path next. Alice writes it once; it comes back on Bob's claim without anyone searching, as an excerpt, never a body:
The full walkthrough, with contracts, notices, and the same calls over raw MCP, is docs/2-examples/01-two-agents-demo.md; the script is examples/demo.sh.
CLI
Every tool has a subcommand; the CLI uses the same MCP path agents do.
--agent sets your name, --json prints the raw result, and non-ok
outcomes exit with status 1.
Swarm lead and escalations
The session that spawns other agents claims the reserved path
.tirith/lead and becomes the swarm lead; status and the dashboard show
who holds it. The daemon then handles routine escalations with fixed
rules, without spending an LLM turn:
- What escalates: a task set to
blocked(its note is the reason), or the third refusal of the same claim within 360 s. A message to the lead is never an escalation. - Where it goes: while there is a lead, to the lead's inbox as a
message from
tirith, tagged "may need the human" when it mentions credentials, permissions, spending, or destructive steps. Nothing reaches you on its own: the lead relays what needs you withmessage_sendtohuman, written for you. While there is no lead, escalations go to your queue. - Your queue: the dashboard's "Needs you" list,
tirith lead human,/api/humanon the dashboard port, and the macOS tray, which lists each item's sender and first line and notifies you of new ones. Answer with the dashboard's Done button ortirith lead human done <id> --reply "..."; the reply reaches the sender as a message fromhuman.
Related MCP Servers
Reviews
No reviews yet — be the first to share how this listing worked for you.
Frequently Asked Questions about Tirith
AllMCPs Directory Badge
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
Badge Style:
Live Dynamic SVG Preview
Markdown (GitHub README)
[](https://allmcps.com/mcp/tirith)HTML Embed
<a href="https://allmcps.com/mcp/tirith"><img src="https://allmcps.com/api/badge/tirith?style=directory" alt="Tirith on AllMCPs" /></a>