Tirith
概要
作者による説明(英語の原文)
Coordination server for parallel coding agents: claims, contracts, notices, and memory notes.
できること
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
- 接続方法: パソコンで動く
- トランスポート: stdio
- カテゴリ: 開発者ツール
インストール
使っているAIアプリを選んで、設定をコピーしてください。
チェック 2/2 合格 · あなたのパソコンで動きます
まず:どの AI を使っていますか?
使っているアプリを選ぶと、下に手順が表示されます。
Claude はまだ Tirith につなげません
提供元はまだ MCP Registry にインストール方法を載せていません
ChatGPT はまだ Tirith につなげません
提供元はまだ MCP Registry にインストール方法を載せていません
代わりにできること
B · 開発者ツール の中で ChatGPT につなげる別のサーバー
同じカテゴリでよく使われているものから、キーなしでアドレスだけでつなげるものを選びました
- Sentry✓ ChatGPT
- Front-End Checklist✓ ChatGPT
- Compiler Explorer✓ ChatGPT
Claude Code はまだ Tirith につなげません
提供元はまだ MCP Registry にインストール方法を載せていません
Cursor はまだ Tirith につなげません
提供元はまだ MCP Registry にインストール方法を載せていません
VS Code はまだ Tirith につなげません
提供元はまだ MCP Registry にインストール方法を載せていません
ひと目でわかる
- 接続方法
- パソコンで動く
- トランスポート
- stdio
- 最新バージョンi
- 1.2.0
- レジストリ公開日i
- 2026年9月19日
- コードの最終更新i
- 2026年10月11日
- 作者
- eabz
- パッケージ
cargo: tirith-mcp- ウェブサイト
- eabz.github.io
- レジストリでの状態
- 有効
使えるアプリ
このサーバーのつなぎ方と、各アプリの公式ドキュメントに基づきます。2026年11月10日に確認。
パソコン上で動かせるアプリ
GooseLM StudioMsty StudioCherry StudioVisual StudioWindsurf (Devin Desktop)ZedKiroClineContinueJetBrains AI AssistantCodex CLIGemini CLIOpenCodenodecodeWarpLibreChatRaycast
できること
パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。
基本チェックi
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月11日にチェック
- ✓ 合格
作者とリポジトリが一致
レジストリ名は、リポジトリを所有するGitHubアカウント eabz で確認済みです
- ✓ 合格
今もメンテナンスされている
コードの最終更新:31 日前
- … 未チェック
ライセンスがある
このリポジトリはまだGitHubから読み取っていません
- – 対象外
エンドポイントが応答する
これはパソコンで動くため、インターネット上のエンドポイントはありません
- – 対象外
OAuthでサインイン
パソコンで動き、代わりにローカルの設定を使います
- … 未チェック
ツールの説明に隠れた指示がない
パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです
話し合い
質問、コツの共有、使えないことの報告ができます。「役に立った」の多い順です。
ユーザーレビュー
まだレビューはありません
開発者ツールのほかのサーバーとの比較i
- このカテゴリのほかの5752件のうち83%よりスターが多い
- このカテゴリのほかの5752件のうち40%より最近レジストリに公開
- 基本チェックの結果が、このカテゴリのほかの5752件のうち100%と同じかそれ以上
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
よくある質問
Tirithは安全ですか?
当てはまる基本チェック2項目のうち2項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
どんなキーやコードが必要ですか?
レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。
パソコンで動きますか、それともクラウドですか?
あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません(サーバー自体がオンラインサービスを呼び出す場合を除きます)。
今もメンテナンスされていますか?
GitHubリポジトリの最終更新は31 日前、最新バージョン(1.2.0)がレジストリに届いたのは2 か月前です。
どのアプリで使えますか?
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにRustも必要です。
代わりに使えるものは?
同じカテゴリには:REA, Netdata, Front-End Checklist
代わりの候補
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:↓ 週あたりのダウンロードi★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i
Netdata
Real-time infrastructure monitoring with metrics, logs, alerts, and ML-based anomaly detection.
Front-End Checklist
Review frontend code and live pages against 386 quality-gated web development rules.
作者のREADME
READMEを開く
作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。
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:
curl -LsSf https://eabz.github.io/tirith/install.sh | sh
Windows (PowerShell):
irm https://eabz.github.io/tirith/install.ps1 | iex
With cargo (the package is tirith-mcp, the binary is tirith):
cargo install tirith-mcp
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
In the repository, run:
tirith init
It registers tirith stdio in .mcp.json and puts a short block in AGENTS.md (--file for another). The protocol itself, from the first claim to who leads a swarm, arrives as the MCP server's instructions every time a session connects; a repository that wants its own protocol keeps it in .tirith/instructions.md (tirith init --instructions writes the built-in one there to edit). Other clients register the same command by hand: the shim 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. To run several agents at once, paste the protocol block from docs/2-examples/03-swarm-playbook.md into your project's agent instructions: it says which session leads, when it spawns workers, what each worker is told, and which model each runs on. The daemon serves the same rules in its instructions.
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. |
Twenty-two tools, each with a description of every parameter, MCP annotations, and an output schema, plus the protocol as the server's instructions on connect (ADR-0038). 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:
tirith claim --agent alice --reason "refactor session handling" src/auth/
ok alice src/auth expires 04:14:34Z
tirith claim --agent bob --reason "fix login redirect" src/auth/login.rs
conflict src/auth/login.rs overlaps src/auth (alice: "refactor session handling", expires 04:14:34Z)
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:
tirith memory write --agent alice "Session ids are opaque" -k gotcha --path src/auth/ <<'NOTE'
Tokens are opaque strings. Compare them, never parse them. NOTE
tirith release --agent alice tirith claim --agent bob --reason "fix login redirect" src/auth/login.rs
ok bob src/auth/login.rs expires 04:14:34Z
memory:
session-ids-are-opaque gotcha 04:04:34Z paths src/auth Session ids are opaque: Tokens are opaque strings. Compare them, never parse them.
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.
tirith serve # run the repo's daemon by hand
tirith stdio # per-session shim clients spawn; starts the daemon if needed tirith update # replace the binary with the latest release tirith status # counts, and who holds what tirith init [--file AGENTS.md] [--instructions] # register the server, add the agents block tirith claim | release | renew | claims tirith task create | pull | update | list tirith contract publish | get | list tirith notice publish | list tirith decision record | list tirith memory write | read | search | delete # body from --body, --file, or stdin tirith message send | list # talk to other agents; the inbox shows on any result tirith lead log # the swarm lead and its policy's decisions tirith lead human # items waiting for you, most agents blocked first tirith lead human done [--reply TEXT] # answer one; the reply reaches its sender tirith tray # macOS only: menu bar icon listing every daemon tirith tools # list tools with descriptions tirith call ' ' # call any tool directly
--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 is the lead's: while it holds
.tirith/lead, only the lead publishes contracts, creates tasks, records decisions, deletes memory notes and forces another agent's task; anyone else getsconflictnaming the lead and proposes the change withmessage_send(ADR-0036). With no lead nothing is gated. The lead is also the only session that commits, pushes, opens pull requests or deploys (ADR-0037). - 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 --reply "..."; the reply reaches the sender as a message fromhuman.
Claim grants, refusals, waits, releases and lease ends, notice pushes, and escalations are appended to the lead decision log: tirith lead log, or /api/lead on the dashboard port. Design: ADR-0027; per tool: 04-primitives.md.
Documentation
| Section | Contents |
|---|---|
| 1-about | Purpose, architecture, project structure, tool reference, installation |
| 2-examples | The demo, client setup for every supported framework, and the swarm playbook: lead, workers, briefs, models |
| 3-tests | Testing strategy |
| 4-style | Rust rules and their sources, git conventions |
| 5-decisions | Architecture decision records |
| 6-agent-workflow | How agents work on thi