Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CONTINUUM_MCP_TOKENNoShared 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_TOKENSNoPer-caller secrets in 'name:secret' comma-separated pairs. Used for caller authentication when CONTINUUM_MCP_TOKEN is set.
CONTINUUM_MCP_CONFIRM_TOKENNoSeparate secret required for the continuum_confirm tool. Refuses all callers until set, preventing agents from confirming their own reported state.
CONTINUUM_MCP_MUTATING_CLIENTSNoComma-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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 key identifying the specific operation (for example the invoice id or external resource id), not incidental formatting. The key is what makes two attempts count as the same action, so reuse the exact same key for the same operation across sessions; a key derived from the resource identity makes deduplication immune to argument formatting differences (relative vs absolute paths, argument naming, and so on).

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 13 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityActive
ResponsivenessSyncing