LightWorker
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LIGHTWORKER_HOME | No | The directory where LightWorker stores its SQLite database, worktrees, and state. Defaults to the platform-specific state directory (e.g., %LOCALAPPDATA%\LightWorker on Windows or ${XDG_STATE_HOME:-$HOME/.local/state}/lightworker on macOS/Linux). |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| orchestrateC | Queue a bounded Lead Codex planning run. It creates a dependency-aware task graph and automatically dispatches allowed child tasks. |
| delegate_taskA | Queue one bounded worker task. Explore/review are read-only; execute uses an isolated git worktree and may require approval. |
| delegate_batchB | Queue up to the configured limit of already-decomposed worker tasks. |
| get_taskB | Get one task, its dependencies, and structured result when available. |
| get_task_treeB | List every task belonging to an orchestration root. |
| list_tasksA | List recent tasks, optionally filtered by status. |
| wait_tasksA | Wait up to 55 seconds for tasks to reach a terminal or approval state. |
| get_eventsA | Read append-only task events after an event cursor. |
| get_cache_metricsA | Return materialized cold/warm cache telemetry and target status without scanning event JSON. |
| approve_taskA | Release one task that is awaiting approval into the execution queue. |
| cancel_taskA | Cancel a queued or active task and terminate its worker process tree. |
| retry_fallbackA | Clone a failed read-only task onto its configured fallback gateway. Never falls back automatically. |
| escalate_taskA | Create one budgeted read-only retry using a deeper worker profile. The original task remains unchanged. |
| doctorA | Check local Codex, proxy ports, state paths, model allowlist, and concurrency. |
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 14 tools
Most tools are clearly distinct (queue, inspect, wait, approve, cancel, retry), but retry_fallback and escalate_task both handle failed read-only tasks with overlapping semantics, potentially causing misselection.
Predominantly follows a lowercase verb_noun pattern (delegate_task, get_task, list_tasks), with a few deviations like 'orchestrate' and 'doctor' that are still readable but break the pattern.
14 tools cover a complex orchestration lifecycle (planning, delegation, monitoring, control, retry) without redundancy; each tool serves a distinct operational need.
Covers the full task lifecycle: creation, retrieval, monitoring, approval, cancellation, retry strategies, plus diagnostics and telemetry. No obvious dead ends or missing core operations.