ResumeState MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RESUMESTATE_API_URL | No | The URL of the ResumeState API. Defaults to https://resumestate.com; you don't need to set it. | https://resumestate.com |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| connectA | 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. |
| resumeA | 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. |
| list_lanesA | 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. |
| handoffB | 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. |
| list_artifactsA | 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. |
| get_artifactB | Fetch one artifact's full content by the id list_artifacts (or a resume packet's
|
| replay_searchA | 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. |
| replay_getA | 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 |
| log_sessionB | 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). |
| ingestB | 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. |
| statusB | Check whether this assistant is connected to ResumeState and whether the stored connection is still valid. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
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.