agent-runner-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| task_runA | Run a command inside the evidence-protected sandbox runner (platform ACL/bwrap/sandbox-exec). Returns the job directory; the runner writes lock=pid:startSec and EXIT: on completion. |
| task_waitB | Wait for a task to reach a terminal state (EXIT: written). |
| task_outputA | Read task output from out.log (with byte offset for incremental reads). |
| task_autopsyA | Generate an autopsy report (autopsy-spec format: manner/evidence/verdict/death-code D-01~D-09) for a task directory. |
| task_killA | Kill a running task by its lock pid (SIGKILL) — for crash/adoption experiments. |
| task_adoptC | Three-evidence adoption check: lock pid:startSec parsing + process liveness + exit protocol read. |
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 6 tools
Each tool has a clearly distinct purpose: run starts a task, wait blocks for completion, output reads logs, autopsy analyzes results, kill terminates, and adopt verifies state. No two tools overlap in function; even wait and adopt differ in blocking vs. check semantics.
All tools follow the exact same pattern: task_ followed by a single verb (run, wait, output, autopsy, kill, adopt). This is perfectly consistent and predictable.
With 6 tools, the server is well-scoped for task lifecycle management. Each tool earns its place, covering the core operations without redundancy.
The tool set covers the full task lifecycle: create/run, wait for completion, read output, kill, analyze, and adopt. No obvious gaps for the stated purpose of running commands in a sandbox and managing their results.