MCP server for coding agents
Every coding-agent session on a project lands in one archive, whichever agent each person works in, and every agent reads it back through MCP. So your team stops re-explaining what someone already worked out — and when an agent hits its usage limit, you carry on in another one that knows everything the last one did.
A limit stops the agent. There is no reason it should stop the work, and today it does, because everything you had built up is inside the session that just closed.
How it goes today
With ResumeContext
test_duplicate_charge still failing because the idempotency key is rebuilt per attempt.Three people, three different agents, one archive. Nobody copies anything between them, and nobody writes any of it down.
the team, working as usual
one archive
back inside your session
A lead on the project gets the same archive as everyone else, in whichever agent they already use. Ask it what moved, who is stuck and where two people are duplicating each other. Every answer comes out of the team's own sessions and is cited back to the person and the line, so nobody has to stop and write a status update for you.
charges.ts. She landed a fix on Sep 11, and your session this morning started from scratch. Source: priya@ 019f5a64 · you@ 019f8b02Install the CLI, sign in, and run resumecontext init in the project directory. From then on it syncs on its own. The quickstart walks through it, including connecting your agent.
The ones you already use. A small daemon reads the session history your coding agents write to disk, so there is nothing to install into the agent itself: no plugin, no wrapper, no change to how you prompt. Reading a new agent is a matter of teaching the CLI where it keeps its history, so the list grows; the agents reference has the current one, and you choose which of them to archive per project.
No. You prompt the same way in the same tool. The daemon records in the background and syncs about every twenty seconds; the only difference is that your agent gains a set of tools for searching your team's history, and starts using them when a question calls for it.
The conversation turns for the directory you ran resumecontext init in: prompts, replies, and tool calls with their full output. Worth being plain about: that means source your agent read or wrote is part of the transcript, and therefore part of the archive. It is scoped to that one project and readable only by that project's members.
No. Access is granted per project, and a project is one directory someone ran init in. Being in one project tells them nothing about any other, and the MCP connection your agent uses is scoped to a single project too.
Read it. Of the six tools it gains, four only read; the two that change anything invite and remove project members. The one that runs SQL runs as a database user that holds SELECT on that project's views and no rights to anything else, inside a read-only transaction with row and time limits.
About twenty seconds behind, on every machine that is switched on. The one real gap is the session you are sitting in right now. It has not synced yet, so the archive is the wrong place to ask what you just did.
You revoke them and their access ends immediately. The history they already recorded stays in the archive and stays attributed to them. Removing a person does not rewrite the project's past, and the rest of the team does not lose the reasoning behind their work.
Nothing while it is in beta, and there is no card to enter. We will publish pricing before anything changes. See pricing.
Free while in beta. Two minutes to set up, on each machine.
Get started →