CONTINUUM
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CONTINUUM_MCP_TOKEN | No | Shared secret required for mutating tool calls. When set, the server refuses every mutating tool unless the caller presents this token in the initialize handshake's _meta.authToken. | |
| CONTINUUM_MCP_CLIENT_TOKENS | No | Per-caller secrets in 'name:secret' comma-separated pairs. Used for caller authentication when CONTINUUM_MCP_TOKEN is set. | |
| CONTINUUM_MCP_CONFIRM_TOKEN | No | Separate secret required for the continuum_confirm tool. Refuses all callers until set, preventing agents from confirming their own reported state. | |
| CONTINUUM_MCP_MUTATING_CLIENTS | No | Comma-separated allowlist of client names permitted to use mutating tools. Mutating tools deny by default if this is not set. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| continuum_record_progressA | Record how far through a task you are. Call this as you complete units of work so progress survives a crash. Creates the run on first call if 'goal' is given. Cheap: call it often. |
| continuum_checkpointA | Save a durable checkpoint of the current task state. Worth doing at milestones, before risky or irreversible steps, and before a long gap. Recovery replays from the newest checkpoint, so checkpointing bounds how much work a crash can cost. Pass 'model_id' with your own model identifier. It is what later lets continuum_resume answer whether the model resuming this work is the one that produced it; without it that check can only report 'unknown'. |
| continuum_record_summaryA | Record a compact summary of WHERE your reasoning is, so a fresh session after any interruption inherits your plan instead of guessing. Call at natural checkpoints and before ending a turn. Schema: {plan_stack: [current step first], decisions: [{what, why}], open_questions: [...], working_set: [files/ids in play]}. Hard cap 4096 characters serialized - summarise, never dump transcripts. |
| continuum_record_planA | Record a structured plan milestone update. Call as you define or complete units so the run can resume with exact remaining work. One call per unit status change. Payload is {plan_id, units: [{id, title, status, depends_on}]} where status is pending, working, done, or blocked. Creates the run if needed. Mutating. |
| continuum_validateA | Check whether saved state is still trustworthy, without changing anything. Pass 'env' as {resource: version} to declare what the world looks like now; a dependency that moved since the checkpoint invalidates the findings built on it. Read-only: safe to call anytime. |
| continuum_resumeA | Ask whether it is safe to continue a run after any interruption, and what to do first. Call this BEFORE resuming work. Returns a mode: 'resume' means proceed; anything else means stop and perform 'next_allowed_action' first. Read-only. If 'run_id' is omitted, targets the most recently active (interrupted) run, so a fresh session can resume without remembering the id. |
| continuum_confirmA | Confirm a run's self-reported goal and progress so it can resume. MCP/agent-reported runs are self_certified and would otherwise be stuck at request_human forever. REFUSED unless the server operator set CONTINUUM_MCP_CONFIRM_TOKEN and you present that secret in the handshake _meta.authToken: an agent must not confirm its own self-reported state. The normal path is for a human to run 'continuum confirm <run_id>' on the host. Pass scope=["goal"] or ["progress"] to confirm only that component, leaving any other uncertainty intact (issue #394). Omit scope for a full confirm of both. Mutates the run. |
| continuum_intercept_actionA | Ask permission before performing an external side effect (creating an issue, sending a message, charging a card). Returns proceed=true if you should do it, or proceed=false with the previous result if it was already done; do NOT repeat it in that case. If a previous attempt was interrupted, returns proceed=false with status='unknown': the effect may or may or may not have happened, so stop and ask a human. After performing the action, always call continuum_complete_action. Pass a stable |
| continuum_complete_actionA | Report that an intercepted action succeeded. Call this immediately after performing the side effect, using the action_key returned by continuum_intercept_action. Skipping it leaves the action uncertain and blocks recovery. You may also pass consumed_inputs naming the checkpoint and prior outputs this effect was computed from (checkpoint_seq, event_positions, component_ids, action_ids); it is recorded for restore-point admissibility and defaults to none. |
| continuum_fail_actionA | Report that an intercepted action failed. Set certain=true only if you know nothing happened (e.g. the request was rejected before it was sent). For timeouts or dropped connections leave certain=false: the effect may still have landed, and treating it as failed could cause a duplicate. |
| continuum_reconcile_actionA | Settle an action whose outcome was unknown, after checking the external system. occurred=true records it as done (never repeated); occurred=false frees it to be retried. Only call this with real evidence; guessing here causes either a duplicate or lost work. 'action_key' accepts either the action_key from continuum_intercept_action or the action_id that continuum_resume and continuum_list_actions report, so the identifier named in next_allowed_action can be passed as-is. |
| continuum_compensate_actionA | Record that a completed side effect was deliberately undone (for example a refund or reversion). Call this after executing a compensating action. Marks the action as COMPENSATED. |
| continuum_list_actionsA | List external side effects recorded for a run. Each row carries 'outcome_unresolved': true when that action's real-world outcome is not known and must be reconciled before resuming. Read-only. |
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 13 tools
The side-effect tools have clearly separated roles, as do resume, validate, and confirm. The main ambiguity is among record_progress, record_plan, record_summary, and checkpoint: their purposes differ, but their recommended calling points can coincide, leaving uncertainty about whether multiple calls are expected.
Every tool uses the same continuum_ prefix and snake_case convention. Names are verb-led or naturally verbal, with consistent action-oriented terminology across the side-effect lifecycle.
Thirteen tools is well suited to the combined scope of durable run recovery and safe external side effects. Each tool supports a distinct lifecycle step without obvious redundancy or unnecessary expansion.
The surface covers run state capture, planning, checkpointing, validation, confirmation, and resumption. It also provides a closed side-effect lifecycle from interception through completion or failure, reconciliation of uncertain outcomes, compensation, and inspection.