pi-delegate-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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| initA | READ THIS FIRST. Reports what this server can reach and how to drive it: permitted tools, the default model, models available per provider, and the recipes for delegating. Every other tool refuses until this has been called once. |
| spawnA | Delegate a task to a pi agent running in the background. Returns a sessionId immediately, so nothing blocks. Poll with |
| spawn_batchA | Fan out several delegates in one call. Each task inherits the batch-level model, cwd, tools and extensions unless it overrides them. The whole batch is validated before any delegate starts, so a bad model name or a duplicate id fails everything instead of leaving half a fan-out running. Poll the result with |
| runA | Delegate a task to a pi agent and wait for the final answer. Blocks until done. Prefer |
| statusA | Check a background pi session. Returns state, turn count, tools used, latest text, and any pending questions the agent is waiting on. A non-empty |
| steerA | Redirect a running pi agent mid-task. The message lands after its current tool call finishes, before the next model call. Use this instead of aborting when the agent is going the wrong way. |
| answerA | Answer a question raised by a pi agent. Get |
| follow_upA | Send another prompt to a delegate that has already finished, keeping everything it read and said. Use this instead of spawning a fresh delegate and re-explaining the task: the session still holds its own context, which yours never had to absorb. Returns immediately; poll with |
| abortA | Stop a running pi session. Partial output stays readable via |
| sessionsA | List pi sessions held by this server, running and finished. Finished ones stay readable for review until evicted (keeps the newest 50). |
| forgetA | Drop a finished session from the review history, freeing its id for reuse. |
| modelsA | List models this delegate may use: pi's own scoped set plus any custom provider. Use to pick a |
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 12 tools
Each tool targets a distinct phase of the delegate lifecycle: starting (spawn, run, spawn_batch), monitoring (status, sessions), interacting (steer, answer, follow_up), and cleanup (abort, forget). Descriptions clearly differentiate async vs sync and running vs finished states, so misselection is unlikely.
Most tools use imperative single-word verbs (spawn, steer, abort) or compound verbs (spawn_batch, follow_up), but two are bare nouns (sessions, models) instead of list-style verbs like list_sessions. This is a minor deviation from an otherwise predictable, straightforward naming scheme.
At 12 tools, the server is well-scoped for its purpose—managing delegated pi agents. Each tool covers a necessary operation without redundancy, and the count falls comfortably within the 3–15 ideal range for a focused MCP server.
The tool surface provides full lifecycle coverage: launch, monitor, interact, redirect, follow-up, abort, clean up, and list. It also includes init and models for setup and model selection. There are no obvious gaps that would cause agent dead-ends.