omp-worker-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OMP_WORKER_OMP_COMMAND | No | Path to the OMP CLI executable, used if 'omp' is not on the 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 |
|---|---|
| omp_run_batch_compactA | Submits a decomposed group of OMP tasks to execute concurrently in the server-side bounded rolling pool (max_parallel 1-10) using a detached group runner. Enforces dependency DAG and write-ownership safety, waits up to wait_seconds (0-240, default 60s) for batch completion, and returns stable compact aggregated results. If still running when deadline elapses, returns group_id and minimal progress counts for subsequent omp_wait_group. |
| omp_wait_groupA | Wait for an existing OMP task group to reach a terminal status, polling up to wait_seconds (0-240, default 60s). If completed, returns full aggregated compact results in original input order. If still running when deadline elapses, returns minimal progress counts without leaking task summaries. |
| omp_cancel_groupA | Request immediate cancellation of a running batch task group and its child tasks. Writes a cancellation request that the detached group coordinator handles safely. Call this immediately when the user asks to stop a batch. |
| omp_run_compactA | Preferred entrypoint for single substantive execution tasks. Creates a delegated OMP task, launches the detached runner, and waits up to wait_seconds (default 60s) for completion in a single MCP call. If finished, returns a compact summary, artifacts, verification, and details_path without dumping the full final response. If still running at the deadline, returns job_id and status running for subsequent omp_wait. |
| omp_delegateA | Low-level background delegation entrypoint. Transfers ownership of an execution task to OMP and returns immediately with job_id. Prefer omp_run_compact for standard workflows to avoid separate delegate/wait round trips. |
| omp_cancelA | Request immediate cancellation of one exact delegated OMP job. The detached runner owns the OMP child PID and terminates that process tree safely. Call this immediately when the user asks to stop; do not inspect PIDs or manually kill processes first. |
| omp_waitA | Wait for an existing OMP job to reach a terminal status, polling up to wait_seconds (default 30s, max 60s). Returns the current status and summary once terminal or when the wait deadline elapses. Avoid polling in a tight loop. |
| omp_resultA | Retrieve full details of a terminal OMP job, including finalResponse and attempt logs. Call this only when minimal acceptance check fails, high-risk operations occurred, or the user explicitly asks for full inspection; do not call this after every successful compact run. |
| omp_continueA | Resume the same OMP session with targeted supervisory feedback to correct specific acceptance defects without starting a fresh task from scratch. Bounded to remaining attempts within max_attempts. |
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 9 tools
Each tool has a clearly distinct purpose: batch vs single, delegate vs wait vs cancel vs result retrieval vs continue. No two tools overlap in function—omp_run_compact and omp_delegate differ by synchronous vs asynchronous, and omp_wait_group vs omp_wait serve batch vs single jobs.
All tools follow a consistent `omp_<verb>[_<noun>]` pattern where the verb describes the action (run, wait, cancel, result, continue) and optional noun specifies the target (batch, group, compact). Perfectly predictable and uniform.
9 tools precisely cover the lifecycle of both single and batch task execution: submission, waiting, cancellation, result retrieval, and continuation. No tool is superfluous, and the count is tight for the complexity of the domain.
The tool surface covers every stage of task management: submission (run/delegate), monitoring (wait), cancellation (cancel), post-hoc inspection (result), and iterative correction (continue). No obvious gaps—both single and batch workflows are fully supported.