codex-monitor
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_MONITOR_HOME | No | Optional. Overrides the configuration directory used for custom probes. Defaults to platform-specific path. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| monitor_createA | Create a background monitor that watches for a condition and settles when it becomes true. Evaluation happens inside the plugin, so never write your own sleep/poll loop. Returns a monitor id; pass it to monitor_wait to pause until the condition holds. Use this for anything long-running: cluster jobs, builds, deploys, downloads, servers coming up. Installed condition types: command, file, log. |
| monitor_waitA | Block until the given monitor(s) settle (satisfied, failed, timeout, or cancelled). mode 'all' waits for every listed monitor; 'any' returns as soon as one settles. If wait_timeout_seconds elapses first, returns outcome 'wait_timeout'. Monitors keep running whenever a wait ends early, including when the call is interrupted, so call monitor_wait again with the same ids to resume. |
| monitor_runA | Convenience: monitor_create + monitor_wait in one blocking call. Creates the monitor and pauses until it settles (or wait_timeout_seconds elapses, in which case the monitor keeps running and you can monitor_wait on the returned id later). |
| monitor_statusA | Snapshot of monitors without blocking. Omit ids for all monitors. Use for a quick look; use monitor_wait (not repeated status calls) to wait for completion. |
| monitor_cancelA | Stop an active monitor. Settled monitors are left untouched. |
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 5 tools
Each tool has a clearly distinct role in the monitor lifecycle: create, wait, run, status, and cancel. There is no overlap—monitor_run combines create and wait, but it is a convenience wrapper rather than a competing tool.
All tool names follow the same `monitor_<verb>` pattern, making the action and resource predictable. The verbs are consistent and match the function of each tool.
Five tools cover the full monitor workflow without bloat or missing essentials. This is a well-scoped set for a monitoring utility.
The set provides complete lifecycle coverage: create, wait, cancel, status, and a combined create-and-wait convenience. There are no obvious dead ends—a user can create, monitor, and clean up monitors with these tools.