sub-pi-agent
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 |
|---|---|
| pi_list_modelsA | List Pi models available for this session with tier labels (fast/balanced/frontier). |
| pi_spawn_agentA | Start a named Pi agent asynchronously. Returns identity/status, not a completed result. Continue independent work; when idle, call pi_wait_agent instead of repeatedly polling. pi_poll_agent reads progress or a needs_input question; answer through pi_continue_agent on the same ID. Read final delivery with pi_get_result once done. Unread events may accompany any tool response; no live notifications. Use pi_list_agents for reuse. Omit model to follow Pi settings. |
| pi_steer_agentA | Queue a steering message for a running Pi agent. Returns the message verbatim plus a delivery status: {ok:true,message,status:"queued"} means only that Pi accepted it for delivery after the current assistant turn finishes its tool calls — it does NOT mean the message was delivered or that Pi has responded. {ok:false,message,status:"rejected",reason} means nothing was sent (unknown session, session not running, or Pi refused the steer). Use pi_followup_agent to queue a message for after all work is finished. |
| pi_followup_agentA | Queue a follow-up message for a spawned Pi agent. Delivered only after the agent finishes all work. Use this when you do not want to interrupt the agent at all. |
| pi_poll_agentA | Immediately read latest assistant text, compact activity metadata and any pending question, without reasoning text or raw tool records. output can stay unchanged while Pi thinks or runs tools; activity shows the latest phase/tool and its update time. needs_input returns question {id,text}: answer via pi_continue_agent on the same ID. Reading a question acknowledges its reminder; polling does not acknowledge final delivery. When idle, use pi_wait_agent instead of repeatedly polling. |
| pi_wait_agentA | When no independent work remains, wait for this agent to need input, finish, fail or be interrupted. The MCP process waits without calling a model; progress changes alone do not wake it. Already actionable states return immediately. Returns {status,timed_out,next}; no progress, question or delivery body, and no event acknowledgement. On timeout Pi keeps running: wait again or inspect progress. Read questions with pi_poll_agent and final delivery with pi_get_result. Cancelling the wait does not stop Pi. |
| pi_get_resultA | Read final delivery, without waiting: done returns the last Pi reply, error/interrupted returns the final partial reply and error in the JSON body. Before final delivery exists, returns only {ready:false,reason,next}, never progress or a question body; use pi_poll_agent. Reading final delivery acknowledges its unread event. Results remain readable after release or MCP restart. |
| pi_list_agentsA | List only this MCP registry, including unloaded recoverable agents. Compact identity/status metadata, no transcript. active means running; needs_input means Pi handed back a question: poll it, then continue the same ID with an answer. Listed agents become eligible for this connection's unread event reminders. Does not refresh idle timers. |
| pi_continue_agentA | Continue a registered agent by explicit ID, retaining its Pi conversation/tool context. For needs_input, pass the answer as task; otherwise pass the next assignment. Returns identity/status immediately. Do independent work or use pi_wait_agent when idle; pi_poll_agent inspects progress/questions and pi_get_result reads final delivery. Restores released sessions after MCP restart, rejects running agents, never imports arbitrary Pi CLI sessions. Omit model to follow current Pi settings. |
| pi_release_agentA | Unload an idle agent runtime and release its write lease, retaining its name, description, results and native Pi session on disk for later continuation. Rejects busy agents. Does not delete the agent or its context. |
| pi_terminate_agentA | Stop the current task, mark it interrupted, and return its partial latest reply. Retains the registered agent and context for explicit continuation; use pi_release_agent to unload an idle runtime. |
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 11 tools
Most tools have clearly distinct purposes (spawn vs continue vs poll vs get_result vs terminate vs release). However, pi_steer_agent, pi_followup_agent, and pi_continue_agent all send messages to agents with subtly different timing; while descriptions clarify, an agent could still momentarily confuse which to use.
All tool names use a consistent snake_case pi_ prefix followed by verb_noun (pi_spawn_agent, pi_list_agents, pi_get_result, etc.). The pattern is predictable and readable throughout.
With 11 tools, the set is well-scoped for asynchronous agent orchestration. Each tool covers a distinct lifecycle operation (spawn, list, poll, wait, continue, steer, followup, terminate, release, get result, list models) without redundancy.
The surface covers the full agent lifecycle: creation, monitoring, interaction, termination, and release, plus model listing. The only minor gap is the absence of a permanent delete operation—release intentionally retains agents, so cleanup beyond unloading is not possible.