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., "@ResumeState MCP Server resume my checkout-refactor lane and show the latest handoff"
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.
Session continuity for AI assistants: resume any work lane where the last session stopped.
ResumeState keeps track of where your work stands: what was tried, what was decided, what's done and what failed. It files that under named lanes, one per line of work, so the next session can pick up where the last one stopped, on any model or vendor. This MCP server gives an assistant the tools to do that.
Tool | What it does |
| Links this assistant to your ResumeState account with a short approval code (OAuth 2.0 device flow, RFC 8628) |
| Fetches a lane's latest handoff, or the account-wide packet and its lanes |
| Lists your lanes (code, name, last handoff, freshness) |
| Records one structured handoff under a lane: tried, decided, done, failed, state, pointer |
| Shows artifact cards first, and full content only when it's needed |
| Finds routines that worked, from the replay pool |
| Session bookkeeping, transcript ingest, and connection status |
Related MCP server: agent-runtime-mcp
You need Python 3.10+ and uv. Nothing to clone.
Claude Desktop (one-click bundle)
Download resumestate-mcp-1.0.0.mcpb from the latest release
and open it in Claude Desktop to install it.
Claude Code
claude mcp add resumestate -- uvx --from git+https://github.com/Resume-State/resumestate-mcp resumestate-mcpClaude Desktop, Cursor and other MCP clients (claude_desktop_config.json, .cursor/mcp.json, ...)
{
"mcpServers": {
"resumestate": {
"command": "uvx",
"args": ["--from", "git+https://github.com/Resume-State/resumestate-mcp", "resumestate-mcp"]
}
}
}Then ask your assistant to run connect. It shows you a link and a short code. Approve it in your ResumeState account,
and the assistant gets its own pass.
No API key in your config. connect uses the OAuth 2.0 device flow: you approve the assistant on the website,
and it gets a pass scoped to your continuity.
The pass stays on your machine. It's kept in ~/.resumestate/mcp-token.json, readable by your user only, and
renews itself. It's never printed.
The pass is narrow. It can't reach your keys, billing, password or other AIs. You can see it and switch it off under Connected AIs in your account.
No configuration needed. RESUMESTATE_API_URL defaults to https://resumestate.com; you don't need to set it.
Connecting an AI is part of a ResumeState membership. Every plan starts with a 7-day free trial (a card is asked at checkout; cancel anytime). Prices are in Canadian dollars:
Plan | Monthly | Yearly (20% off) |
Solo | $9.99 CAD | $95.88 CAD |
Team | $19.99 CAD | $191.88 CAD |
Enterprise | $99 CAD | $950.40 CAD |
See the plans and the guide to MCP continuity servers.
Your continuity stays private to your account, and to your team on Team. This client talks only to the ResumeState API at the address above. Read the privacy page.
MIT. See LICENSE.
Connect this assistant to a ResumeState account. Mints a short approval code and link; if it doesn't finish within about a minute, approve at the link and call connect again.
Inputs: no named parameters.
Fetch one artifact's full content by the id list_artifacts (or a resume packet's
artifacts cards) gave.
Inputs: artifact_id (required).
Record one rule-16 HANDOFF entry under a work lane: what was tried, decided, done, and failed, plus where things stand (state: working/failed/open/blocked) and a pointer to detail. Use the lane's code from list_lanes as lane_code.
Inputs: by (required), done (required), state (required), tried (required), +6 more.
Upload a session transcript or checkpoint to ResumeState so a future session can resume from it. The upload itself stays private to this account and never enters the replay pool; once member sharing starts, routines from your sessions may be shared as your plan says.
Inputs: content (required), project, filename.
List this account's artifacts as short cards (id, title, kind, one-line summary, link) — optionally only those pinned to one work lane. Bodies are NOT included: call get_artifact with an id only when that artifact's full content is actually needed.
Inputs: lane_code.
List this account's work lanes (code, name, last handoff time, freshness) — pick one of these codes to pass to resume/handoff so a session's continuity follows its own work lane.
Inputs: no named parameters.
Record that a session under the given label happened, for this account's own session bookkeeping (separate from the per-lane continuity resume/handoff track).
Inputs: label (required).
Fetch one replay by its code (RP- and ten hex digits): its steps and templates, each step's
effect (read / idempotent-write / destructive) and whether it is checked, the slots to fill, the
evidence, its lifespan, the live record from runs, and policy -- the fixed rules for running
it. Follow the policy: stop at the first failed step; idempotent writes need the user's
permission; destructive steps need the owner's explicit yes.
Inputs: code (required).
Find replays (routines that worked in real sessions, with the values we can recognise turned into blank slots) this account can use, as short cards: code, title, topic, pool, kind, risk, proven, status. Optionally narrow by words in the title or by a topic (e.g. version-control, testing, databases). Call replay_get with a code for the steps.
Inputs: query, topic.
Fetch the connected ResumeState account's continuity. With a work-lane code (list_lanes gives the codes), returns that lane's own latest handoff + its children instead of the account-wide packet. With neither project nor lane_code, the packet also lists the account's lanes so a caller with no code yet can pick one. Reports a not-yet-current compile state instead of stale packet content.
Inputs: project, lane_code.
Check whether this assistant is connected to ResumeState and whether the stored connection is still valid.
Inputs: no named parameters.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 11 tools
Most tools have distinct roles: replay_search/replay_get and list_artifacts/get_artifact are clean card-then-fetch pairs, and connect vs status are related but distinguishable. However, handoff, log_session, and ingest all read as 'record activity for this account,' and resume's fallback to listing lanes overlaps with list_lanes, creating some boundaries an agent could misjudge.
A clear verb_noun convention exists in list_lanes, list_artifacts, get_artifact, and log_session, but replay_search/replay_get invert it to noun_verb while connect, resume, handoff, ingest, and status are bare verbs/nouns with no shared pattern. The mix is still readable in context but not predictable.
Eleven tools is well within the ideal 3-15 range and each earns its place across connection, continuity, lanes, artifacts, replays, and ingestion. Nothing feels padded or missing at the count level.
The surface covers the continuity lifecycle well: connect/status for auth, resume/handoff for per-lane state, list_lanes for navigation, artifacts and replays for retrieval, and ingest/log_session for recording. Artifacts are read-only with no create/update/delete exposed, and lanes have no management operations, but these are plausible external responsibilities rather than dead ends.
Persistent work tracking for AI agents: tasks, status and history that follow you across machines
Gives your AI assistant persistent memory and intelligence about your work patterns.
Shared task layer for AI agents: tasks, handoffs and decisions that persist across tools.
Durable agent-to-agent handoffs and shared scratchpad for multi-agent workflows.
