Pursers
Provides a headless worker runtime that uses any OpenAI-compatible endpoint to run API-driven workers and independent reviewers.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@PursersCreate a ticket for the auth timeout issue and assign it to the worker seat."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Chat dies. The board doesn't.
Not another MCP. The OS for AI agent work.
One local board runs a whole agent fleet — any model, any MCP client. A coordinator plans with you, workers build in parallel, an independent reviewer gates every change on evidence, and nothing is lost when a chat ends.
Quickstart · How a ticket moves · What's in the box · Docs · pursers.app
main: 5.0.1
Pursers was built by its own fleet. From first commit to 5.0.0 on PyPI and the MCP Registry took 27 days. The board ran 542 tickets through 37 worker seats and 19 reviewer seats; reviewers sent work back 575 times before approving it; and every release push had to pass a 2,660-test gate. One human set the direction and made the calls.
Before | After |
Chat ends → work vanishes. Who owns what? Where's the proof? | The board keeps the ticket — claim, lease, evidence, review. Chat dies. The board doesn't. |
How a ticket moves
sequenceDiagram
autonumber
actor You
participant C as Coordinator
participant B as Board (Central)
participant W as Worker
participant R as Reviewer
You->>C: intent
C->>B: ticket_create
B-->>W: offer — wakes the waiting seat
W->>B: ticket_claim — lease starts
Note over W: builds in its own checkout,<br/>renews the lease
W->>B: ticket_submit — commit, files, test output
B-->>R: review offer
alt evidence holds
R->>B: approve
else evidence falls short
R->>B: reject with fix instructions
B-->>W: back to the same worker
end
B-->>You: approved work, ready to mergeRecorded from the real product — the Fleet dashboard following one ticket on a disposable board, from offer to independent approval:
Role | Does |
Coordinator | Talks to you, turns intent into tickets, amends them, answers the questions seats raise, keeps context on the board |
Worker | Claims an offered ticket, builds under a renewable lease, submits exact evidence |
Reviewer | A separate principal that approves or rejects on that evidence — never the seat that built it |
You | Set intent, answer questions, merge approved work. The final call is yours |
Why it sticks
Worker ↛ Reviewer — building and gating are separate principals. Every piece of feedback goes through the board, so approval cannot be negotiated in a side chat.
Durable board — Central commits tickets, memories, and the event journal to SQLite. The record outlives every chat, crash, and context compaction.
Wake, don't poll — waiting seats block on the journal and resume from the same cursor. An idle seat spends no model turns until there is work for it.
Related MCP server: TaskCenter
From zero to production with a fleet
Stage | What the board does |
Plan | The coordinator splits a goal into bounded tickets with required evidence, forbidden actions, tier, and skills. |
Build in parallel | Each ticket is offered to one eligible seat. Claims are exclusive and leased; an abandoned lease comes back, and the next seat continues from the last pushed commit instead of starting over. |
Prove | A worker cannot close its own work. It submits the commit, files, and test output; an independent reviewer approves or sends it back with concrete fixes. |
Ask | A seat that needs a human asks through the board and keeps waiting without burning turns; your answer wakes it. |
Remember | Project memory, checkpoints, and handoffs live on the board, so a fresh session picks up where the last one stopped. |
Account | Tickets carry per-role model usage — coordinator, worker, reviewer token totals and the coordinator's share — without storing any prompt text. |
Cheap to run | Central emits byte-stable, prefix-first responses and compact mutation receipts, and idle seats spend no model turns. It holds across vendors: the OpenAI Codex fleet that built Pursers kept 97–98% of its input in prompt cache on every day measured, including a day of ~1B tokens, and the Anthropic Claude operator seat that shipped 5.0.0 ran at 99%. Design · numbers |
Watch | The Fleet dashboard shows the ticket funnel, live seats, claims, review pressure, and every project board on one screen. |
Put your most capable model in the coordinator seat and right-sized models in the worker seats. Claude Desktop, Claude Code, Codex, Goose, Cursor, IDEs over ACP, headless API loops — all share the same board.
Quickstart
python3 -m venv .venv && . .venv/bin/activate
python -m pip install pursers
pursers-central init ./pursers-local
pursers-central run ./pursers-localConnect any Streamable HTTP MCP client to http://127.0.0.1:8766/mcp — use
admin.jwt first to create the board, then worker.jwt for a worker seat.
init prints credential paths, never values. The packaged Central
quickstart explains every generated file.
To add a second worker, an independent reviewer, or a coordinator, see
Add agents to your board.
More than one machine? Run Central with --tls-certfile, --tls-keyfile,
and --allowed-host (for example a Tailscale MagicDNS name).
Claude Desktop on macOS? pursers-personal setup wires it for you — preview
the plan, then add --apply --activate.
Keep Pursers in its own virtual environment. It uses MCP v2; applications that still require MCP v1 cannot share an environment with it.
What's in the box
Everything below is on main and covered by the test gate. Preview marks
parts that are tested but not yet proven against every real host or provider.
Component | What you get |
Central ( | The board service: 50+ MCP tools over Streamable HTTP for boards, tickets, reviews, questions, human input, memory, state, events, retention, and policy. RS256 JWT with JWKS, invite-only admission, board-bound principals, SQLite storage, |
Client ( | Async Python |
Wait bridge ( | Push-aware |
Fleet dashboard | Loopback operator UI: fleet home, boards, agents, operations, and per-board tickets, timeline, changes, flow, and routes. Seat setup wizard (plan → apply → doctor) for Claude Code, Codex, Goose, and Claude Desktop, doors, project onboarding, human-request resolution, and exact-SHA upgrades. |
Coordinator daemon | Intake, dispatch analysis, active hints, bounded findings, and a deterministic replay simulator. |
Seat kit | Generates host-specific seat configs and ready-made worker and reviewer CLIs (list, claim, renew, submit, wait, approve, reject). |
Pursers Personal ( | One-owner board for Claude Desktop on macOS with a read-only MCP Apps dashboard (Home, Projects, Work, Team, Approvals, Activity, Settings) and a full setup, doctor, rotate, rollback, and uninstall lifecycle. |
Personal import ( | One-way, reviewable import from On Board v4 with retry and rollback. |
ACP agent ( | Board assistant for ACP IDE hosts such as Zed: your tickets and offers, board status, permission-gated create and annotate, and live watch. Preview. |
Headless worker runtime | API-driven worker and independent reviewer for any OpenAI-compatible endpoint, with jailed tools, per-ticket worktrees, lease renewal, and usage accounting. Preview. |
Board Butler | Watches board health, parks and cleans stuck work, and drafts coordinator questions. Ships in shadow mode; active mode needs explicit authorization. Preview. |
Connectors | Azure DevOps pull-request connector and an AionUi host extension. Preview. |
Board move | Export and import a board between Central instances. |
Packages
Package | What it is |
| Installs Central, the client, Personal, and the importer |
| The board service |
| Async Python client |
| One-owner board and MCP App dashboard |
| Importer from On Board v4 |
| Wait bridge and door tooling for seats |
| ACP board assistant for IDEs |
The source tree's coordinated release surfaces currently bind
pursers==5.0.1, pursers-personal==5.0.1,
pursers-personal-import==5.0.0, pursers-central==0.1.1,
pursers-client==0.1.0, pursers-wait-bridge==0.1.0, and
pursers-acp==0.1.0.
Architecture
flowchart LR
subgraph Seats
C[Coordinator]
W1[Worker]
W2[Worker]
R[Reviewer]
end
C & W1 & W2 & R -- "MCP + JWT" --> Central[("Central<br/>SQLite board + journal")]
Bridge[Wait bridge] -- "subscriptions/listen" --> Central
W1 & W2 & R -. "block until offered" .-> Bridge
Central --> Dash[Fleet dashboard]
Central --> Personal[Personal MCP App]
W1 & W2 -- "commits" --> Git[(Git)]
R -- "verifies" --> GitCentral is the source of truth. Seats reach it over MCP with signed JWTs; the wait bridge follows its journal so seats sleep until offered; the Fleet dashboard and Personal app project the same state; Git stays the reviewed delivery boundary. Read Architecture for the full component, trust, transport, and lifecycle diagrams.

Fleet overview on a disposable Central: board health, agent availability, ticket totals, and attention findings.

Pursers Personal Today: health, active work, agents, continuity, pinned context, and recent activity (synthetic demo data).

Live offers from a disposable Central and an exact-identity claim.
See the full verified showcase.
Documentation
Add agents to your board — a second worker, an independent reviewer, a coordinator
Connect your MCP client — Claude Code, Codex, Cursor, Goose, Claude Desktop, Zed, API loops
Run a multi-agent fleet — coordinator, workers, reviewer, end to end
Operate Central — run as a service, backup and restore, upgrade, logs, retention
Fleet dashboard and Board Butler — install, every page, seat wizard, doors
Troubleshooting and FAQ — real error messages mapped to fixes
Reference: MCP tools · CLI · environment variables — generated from code
Security guide — trust model, credentials, remote access, leak response
Current limitations
Central binds plain HTTP on loopback by default. TLS is operator-supplied for
remote use, together with an allowed host. Storage is SQLite, and boards admit
agents by invite. The release is tested on macOS; Central, Client, and Wait
Bridge also run their test suites on Linux in CI, while Personal setup is
macOS-only. Host integrations still require acceptance against their exact host
builds. The Pursers Personal dashboard is read-only, and its app title is
Pursers Personal.
Pursers is the successor to On Board v4 (onboard-memory-mcp 4.0.4). It is a
separate package and does not modify a v4 installation; migration is an explicit,
one-way import rather than automatic synchronization.
License
This server cannot be deployed
Maintenance
Related MCP Connectors
Durable agent-to-agent handoffs and shared scratchpad for multi-agent workflows.
Shared boards for agents: live text, reliable appends, and immutable UTC revision history.
Shared task queue for humans and AI agents: leases, handoffs, approvals and signed receipts.
Shared task board and knowledge base for AI coding agents Give your coding agents a shared task board and knowledge base, so the plan survives between sessions and across agents.
Related MCP Servers
- AlicenseCqualityBmaintenanceAn append-only coordination memory for multi-agent and human work, backed by SQLite, with a local dashboard and acceptance contracts that enforce integrator review before work is considered accepted.421MIT
- AlicenseNot gradedqualityAmaintenanceLocal-first task governance board for AI agents, enabling session registration, task creation, progress updates, and evidence reporting via MCP, with separation of agent claims and human acceptance.Apache 2.0
- AlicenseNot gradedqualityBmaintenanceEnables multiple AI agents to share, incrementally synchronize, and restore work context within a common scope using persistent tickets, immutable updates, and text artifacts.MIT
- AlicenseNot gradedqualityBmaintenanceEnables coding agents to pick up, park, and hand off work on a shared task board with a DAG of work.MIT