Skip to main content
Glama
nbhson
by nbhson

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
OPENCODE_BINNoOpenCode binary path.opencode
CLAUDE_CODE_BINNoClaude Code binary path.claude
RECOVERY_DB_PATHNoSQLite database shared by MCP + watchdog (must match between the two processes)../data/recovery.db
RECOVERY_ENABLEDNoGlobal recovery killswitch.true
RECOVERY_POLL_MSNoWatchdog polling interval.30000
RECOVERY_LOG_FILENoOptional JSON log file.
RECOVERY_STALE_MSNoHeartbeat considered stale after 10 minutes.600000
RECOVERY_LOG_LEVELNoLog level: debug | info | warn | error.info
RECOVERY_ALLOWED_DIRSNoComma-separated root dirs; tasks outside are rejected. Empty means unrestricted.
RECOVERY_MAX_ATTEMPTSNoRetry budget per task.5
RECOVERY_BACKOFF_MAX_MSNoBackoff cap.1800000
RECOVERY_MAX_CONCURRENTNoMax simultaneous recoveries.2
RECOVERY_MAX_RUNTIME_MSNoHard runtime cap per recovery launch.3600000
RECOVERY_OWNER_LEASE_MSNoRecovery ownership lease.300000
RECOVERY_BACKOFF_BASE_MSNoInitial backoff between retries.30000
RECOVERY_GENERIC_CLI_NEWNoNew-session template, e.g. myagent run "{prompt}".
RECOVERY_GENERIC_CLI_RESUMENoResume template, e.g. myagent run --resume {session} "{prompt}".

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": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
register_taskA

Register a coding-agent task for monitoring and automatic recovery. The agent (or its launcher) calls this when starting a task so the watchdog can resume it after interruptions.

report_progressB

Report task progress (acts as a heartbeat). Keeps the watchdog from considering the task stale.

save_checkpointA

Persist verified progress so a new session can continue the task after a restart. Include concrete details: steps completed, files touched, next steps. Do not paste raw last output.

report_interruptionB

Report an error or interruption for a task. The watchdog verifies and schedules recovery.

get_task_statusB

Get full task status: state, progress, checkpoint, recovery attempts, recent events.

mark_completedA

Mark a task completed after verifying the final state. Requires a verification note; completion is never inferred from process exit.

cancel_taskC

Cancel a task and stop any further recovery attempts for it.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 7 tools

Disambiguation4/5

Each tool maps to a distinct lifecycle action, but report_progress (heartbeat) and save_checkpoint (durable state) are close enough that an agent could misuse one for the other; the descriptions do clarify the difference. register_task vs report_interruption vs mark_completed are clearly separated by intent.

Naming Consistency5/5

All seven tools follow a strict snake_case verb_noun pattern (register_task, report_progress, save_checkpoint, report_interruption, get_task_status, mark_completed, cancel_task). No deviations or mixed conventions.

Tool Count5/5

Seven tools cleanly covers the register→progress→checkpoint→recover→complete/cancel lifecycle without redundancy. Each tool earns its place in the watchdog workflow.

Completeness4/5

Core task lifecycle is fully covered, including recovery and terminal states. Minor gap: no way to enumerate or query multiple tasks (no list_tasks) and no explicit manual recovery trigger, though the watchdog handles recovery automatically.

Maintenance

ActivityMaintained
ResponsivenessNo issues