What can you do with this server?

This server turns the Pi CLI into a programmable coding sub-agent that any MCP host can use to delegate tasks, track sessions, harvest results, and abort runs. * Delegate tasks to isolated pi -p child processes, with default async mode to avoid tool-call timeouts. * Harvest results with pi_status, using long-polling to wait for a run to finish. * Make scheduling decisions via pi_plan: whether to delegate, how many sessions to fan out, and whether to run sync or async. * Manage sessions: list sessions (optionally filtered by cwd), inspect a session snapshot, and fork a session to try an alternative path. * Kill/abort any running pi run by run ID. * Works as a standard MCP server over stdio, so it can be loaded by ZCode, Claude Code, Cursor, or any MCP client.

How do I use pi-subagent?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pi-subagent Delegate implementing user authentication" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

pi-subagent

by guyiicn

Overview Schema Related Servers Score Discussions

TypeScript

Local

pi-subagent

Turn the Pi CLI (@earendil-works/pi-coding-agent) into a programmable coding sub-agent that any MCP host (ZCode, Claude Code, Cursor, …) can delegate tasks to, track sessions, and kill processes.

pi-subagent is a thin MCP server that wraps pi -p --mode json into 7 structured tools: delegate tasks, harvest results, make scheduling decisions, manage named sessions, and abort runs. Process-isolated, fully session-based, sync/async dual-mode.

Why

Pi is a minimal terminal coding agent. Rather than teaching Pi methodology, this project treats Pi as a delegatable worker: a host agent (ZCode / Claude Code) decides when to delegate, fires off a self-contained task, and harvests the result. One Pi process = one isolated sub-agent run.

Process isolation — each delegation spawns one pi -p child process. A Pi crash only affects that run.
Fully session-based — every task binds to a named session (e.g. feat-auth); subsequent calls auto-continue.
Sync / async — defaults to async (avoids host tool-call timeouts); harvest with pi_status long-poll.
Schedulable — pi_plan is a pure 5-stage decision function (reject / capacity / reuse / modify / mode), fully unit-tested.
Universal MCP — any standard MCP client can load it.

Related MCP server: cursor-agent-bridge

Architecture

┌─────────────────────────────────────────────────────────────┐
│  MCP Host (ZCode / Claude Code / Pi / Cursor …)              │
└───────────────────────────┬─────────────────────────────────┘
                            │ MCP (JSON-RPC over stdio)
                            ▼
┌─────────────────────────────────────────────────────────────┐
│  pi-subagent-server  (Node/TS)                                │
│  ┌────────────┐  ┌──────────────┐  ┌────────────────────┐   │
│  │ Tool layer │  │ Session      │  │ Pi runner          │   │
│  │ (7 tools)  │─▶│ registry     │─▶│ (spawn pi -p)      │   │
│  │ + plan()   │  │ + persist    │  │ parse agent_end    │   │
│  └─────┬──────┘  │ + _snapshot  │  │ + tool_execution   │   │
│        │         └──────────────┘  └─────────┬──────────┘   │
│        │                           ┌────────▼─────────┐     │
│        └───────────────────────────│ Run registry     │     │
│           (kill)                   │ + process-table  │     │
│                                   └──────────────────┘     │
└─────────────────────────────────────────────────────────────┘
                            │ child_process.spawn({ cwd })
                            ▼
                   ┌─────────────────────┐
                   │  pi CLI (0.77+)     │
                   └─────────────────────┘

Three layers with clear boundaries: Tool layer (MCP schema + plan() pure function) / Session registry (state + persistence + redaction) / Runner (spawn pi, parse NDJSON, process table).

Tools

Tool	Purpose
`pi_plan`	Decide: should-delegate, sync/async, how many sessions
`pi_delegate`	Dispatch a task (default async; new sessions wait for handshake)
`pi_status`	Harvest a run's result (long-poll)
`pi_session_list`	List sessions (omit `cwd` for the full set `pi_plan` needs)
`pi_session_snapshot`	Inspect one session
`pi_session_fork`	Branch a session to try another path
`pi_kill`	Abort a run
`pi_task_create`	Create a multi-stage task (host writes `_plan-draft.md` first)
`pi_task_plan`	Dispatch a domain review of the plan (harvest via `pi_status`, verdict auto-parsed)
`pi_task_stage_run`	Run one stage: sync (wait for outcome) or async (returns runId)
`pi_task_stage_collect`	Harvest an async stage run; auto-judges and re-dispatches (max 3), else manual
`pi_task_list`	List tasks (filter by taskId / status)

Review loop: after pi_task_plan, harvest with pi_status(runId). When the run finishes, the server detects it is a review run, parses _plan-reviewed.md, and stores planVerdict / planReviewedPath on the task. Stage prompts automatically include the reviewed plan and the output files of passed dependency stages.

Async stages: pass mode: "async" to pi_task_stage_run to avoid blocking a tool call for the full run (recommended when the MCP host enforces a short tool timeout). Harvest with pi_task_stage_collect(taskId, stageId). Failed attempts re-dispatch under a fresh session name to avoid history contamination; after 3 failures the stage goes manual with a decision panel (retry_with_new_hint is supported via promptHintOverride).

Restart recovery: re-running pi_task_create with the same taskId merges instead of conflicting. Stages whose output file already exists and passes validation are marked passed automatically, so interrupted tasks resume without hand-editing tasks.json.

Session model

Each session has a human-readable name + Pi's UUID + cwd + goal.
First pi_delegate creates the session (goal required); later calls auto-continue.
The registry persists to ~/.pi-subagent/registry.json (atomic write; on restart, interrupted running records are corrected to error).
Concurrency cap: 4 running runs; a single session is never run concurrently.
Tasks persist to ~/.pi-subagent/tasks.json (atomic write; running stages are corrected to failed(interrupted_by_restart) on restart).

Install

git clone <this-repo> && cd pi-subagent
npm install

Prerequisite: the pi CLI is installed (npm i -g @earendil-works/pi-coding-agent) and on PATH.

Configure an MCP host

Add to your MCP client config:

{
  "mcpServers": {
    "pi-subagent": {
      "command": "npx",
      "args": ["tsx", "/abs/path/to/pi-subagent/src/server.ts"]
    }
  }
}

Optional env vars:

PI_SUBAGENT_REGISTRY — registry path (default ~/.pi-subagent/registry.json)
PI_BIN — override the pi executable (used by tests)

Test

npm test           # full suite (140 tests)
npm run test:fast  # dot reporter

Tests use a fake pi (test/fixtures/fake-pi.sh) and cover: async/sync, timeout, kill, session-create-failure, multi-waiter, progress cap, scheduling rules (table-driven + 100-iteration property tests), registry persistence, redaction, etc.

Project layout

src/
├── types.ts                 # all shared types + error codes
├── errors.ts                # ToolError helpers
├── runner/                  # parse.ts, argv.ts, spawn.ts, process-table.ts
├── registry/                # session.ts, run.ts, persist.ts, redact.ts
├── scheduler/               # keywords.ts, plan.ts (5-stage pure function)
├── tools/                   # delegate, status, plan-tool, session, kill
└── server.ts                # MCP entry (stdio)
skills/pi-subagent/          # SKILL.md + delegation-patterns (strategy layer)
test/                        # fixtures/ + *.test.ts
docs/                        # design.md (spec) + implementation-plan.md

Design & process

This project went through collaborative design + 4 rounds of external review before implementation. The spec and plan are committed under docs/:

docs/design.md — full design spec (architecture, tool contracts, error handling, scheduler rules, testing strategy). Every contract is traceable to a review note (R1–R4).
docs/implementation-plan.md — 19 TDD tasks (write failing test → implement → pass → commit).

Key design decisions, all backed by real probing of pi -p output and external review:

cwd ≠ session storage — spawn({ cwd }) controls the working dir; Pi's session files use their default location (doesn't pollute the project).
async default + handshake — new sessions wait for Pi's session event before returning (with a sessionStartTimeoutMs), so the host always gets a real piSessionId.
Multi-stage scheduler — plan() is reject → capacity → reuse → modify → mode, where modifiers stack rather than first-match (a lesson from review round 1).
Progress redaction — tool results are truncated + scrubbed for tokens/keys before being stored.

Status

Working implementation, 140 passing tests. Not yet published to npm — run from source via tsx.

License

MIT

Available Tools

7 tools

pi_delegateC

委派任务给 Pi 子代理（默认 async）

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No
`goal`	No
`mode`	No
`prompt`	Yes
`session`	Yes
`constraints`	No
`runTimeoutMs`	No
`allowUnknownTools`	No

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits but only mentions 'default async'. It does not explain side effects, how results are returned, or whether the tool is idempotent. Critical details are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, but it is overly terse for a tool with 8 parameters. While front-loaded, it lacks structure and does not fully utilize the space to convey necessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (8 parameters, nested objects, no output schema, no annotations), the description is severely incomplete. It fails to cover usage patterns, return values, or async/sync behavior beyond the default.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain any of the 8 parameters, not even the required 'prompt' and 'session'. The enum for 'mode' is mentioned only implicitly as 'default async' but no details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool delegates tasks to a Pi sub-agent with a default async mode. However, it does not differentiate from sibling tools like pi_plan or pi_session_fork, which could have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor are there any preconditions or exclusions mentioned. The description is too brief to inform decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pi_killC

中止 run

ParametersJSON Schema

Name	Required	Description	Default
`runId`	Yes

TDQS

C2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must fully disclose behavior, but it only states '中止 run' without detailing side effects, reversibility, or required permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely short but at the expense of clarity; it fails to provide necessary information, making it underspecified rather than appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A kill operation with one parameter is simple, but the description omits return values, error cases, and prerequisites, rendering it incomplete for reliable agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'runId' has no description in the schema or in the text, leaving its purpose and format entirely unspecified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description '中止 run' conveys the action (abort) and resource (run), but is in Chinese and does not differentiate from siblings like pi_delegate or pi_plan.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to use this tool versus alternatives, nor any context about prerequisites or typical scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pi_planC

调度决策：该不该委派、sync/async、开几个 session

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	Yes
`task`	Yes
`fanout`	No
`estComplexity`	No
`preferredMode`	No

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; the description does not disclose side effects, authorization needs, or whether the tool is read-only or modifies state. The term '决策' implies decision-making but no details on consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one line). It is front-loaded with the core idea, but at the cost of missing important details. It could be slightly expanded without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, parameter usage, or behavioral traits, making it hard for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

0% schema description coverage; the description does not explain parameter semantics beyond their names (e.g., fanout, estComplexity). Field names give some clues but are insufficient for proper invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description '调度决策：该不该委派、sync/async、开几个 session' indicates it is for scheduling decisions, but it is vague. It mentions delegation and session management, aligning with sibling tools like pi_delegate and pi_session_fork, but does not clearly state the tool's specific action or output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when to delegate or not, or how this relates to other tools like pi_delegate or pi_session_fork.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pi_session_forkD

派生 session

ParametersJSON Schema

Name	Required	Description	Default
`to`	Yes
`from`	Yes

TDQS

D1.5/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description is too minimal to disclose behavioral traits like destructiveness, permissions, or lifecycle impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely brief but at the expense of completeness. Not a model of efficiency; it omits essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two required parameters and no output schema or annotations, the description provides zero contextual completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%; description fails to explain what 'from' and 'to' represent, leaving all parameters underspecified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description is a single Japanese phrase '派生 session' meaning 'fork session'. It suggests duplication but lacks a clear verb-resource structure or differentiation from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to fork vs using siblings like pi_session_list or pi_session_snapshot. No context provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pi_session_listA

列 session（不传 cwd 取全量，供 pi_plan 用）

ParametersJSON Schema

Name	Required	Description	Default
`cwd`	No

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full transparency burden. It implies a read-only operation ('list') and explains cwd filtering behavior, but does not disclose potential side effects, auth requirements, or other safety guarantees. Adequate but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the action, and contains no superfluous information. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional param, no output schema), the description covers purpose, parameter behavior, and intended usage context. It does not explain return format, but for a list operation this is acceptable. Slightly more detail would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains that omitting cwd returns all sessions, adding meaningful semantics beyond the bare schema. This provides sufficient guidance for a single optional parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and resource 'session', with additional detail on behavior when cwd is omitted. It also specifies use for pi_plan, distinguishing it from sibling tools like pi_session_fork or pi_session_snapshot.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when to use the tool (for pi_plan) and the effect of omitting cwd. It does not explicitly state when not to use it or mention alternatives, but the guidance is clear enough for an AI agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pi_session_snapshotC

取 session 详情

ParametersJSON Schema

Name	Required	Description	Default
`session`	Yes

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description implies a read operation but does not explicitly state it is non-destructive or disclose any behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise but under-specified. A single phrase with no additional structure or front-loading of key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity (1 param, no nested objects, no output schema), the description is incomplete. No information on return value, behavior, or context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The parameter 'session' lacks any description in both schema and tool description, leaving its meaning ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description '取 session 详情' clearly indicates fetching session details. It distinguishes from siblings like pi_session_list (listing) and pi_session_fork (forking) but does not specify the snapshot aspect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings. No context on prerequisites or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pi_statusC

取 run 结果（long-poll）

ParametersJSON Schema

Name	Required	Description	Default
`runId`	Yes
`waitTimeoutMs`	No

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions 'long-poll' implying blocking behavior, but does not disclose idempotency, destructiveness, authentication needs, or error handling. The transparency is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short (one phrase), which is concise but lacks structure. It front-loads the core purpose but does not provide enough detail to be fully helpful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has two parameters and no output schema, the description is insufficient. It omits details on return format, long-poll behavior nuances, timeout semantics, and relationship to sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain any parameters. 'runId' and 'waitTimeoutMs' remain undocumented in meaning. The description adds no value beyond the schema's structural definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb '取' (get) and resource 'run result' with 'long-poll' qualifier. However, it does not distinguish this tool from siblings like pi_kill or pi_plan, which are distinct actions but no explicit differentiation is provided.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or conditions for use. The description is purely functional.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jul 1, 2026
- First observedpi_delegate
- First observedpi_kill
- First observedpi_plan
- First observedpi_session_fork
- First observedpi_session_list
- First observedpi_session_snapshot
- First observedpi_status

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.8/5.0

Disambiguation5/5

Each tool targets a distinct operation: delegation, kill, planning, session management, and status. No overlap in purpose.

Naming Consistency4/5

All tools share the 'pi_' prefix, but the structure varies: some are verbs (pi_delegate, pi_kill), others are noun_verb (pi_session_fork). Overall readable and consistent prefix helps.

Tool Count5/5

7 tools is appropriate for a subagent manager covering delegation, planning, session lifecycle, and status retrieval.

Completeness4/5

Core operations are covered, though missing explicit session creation or update tools. Forking may serve creation, and kill provides termination.

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AI.TV MCP ServerOAuth
tv.ai
Remote MCP server for AI.TV creators — delegate account operations to your AI agent over MCP.
Entertainment & Media AI & Machine Learning
2
ContextStream BOAuth
io.contextstream
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
Knowledge & Memory Developer Tools
30241
Railway MCPOAuth
com.railway
Develop, manage, and debug Railway projects, services, and deployments from within agents.
Cloud Platforms Developer Tools CI/CD & DevOps
2
KodyOAuth
io.github.kentcdodds
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
Developer Tools Code Execution Command Line
2514

Related MCP Servers

pokeclaw
Coding Agents Code Execution Command Line
madebydia
A
license
Not graded
quality
D
maintenance
Enables MCP clients to spawn and control Codex CLI and Claude Code sessions on the host machine, with session management and filesystem access.
Updated 3 months ago (2026-06-08 12:59 UTC)
4
MIT
cursor-agent-bridge
Coding Agents Developer Tools Code Execution
cybas
A
license
Not graded
quality
B
maintenance
Enables MCP clients like Claude Code to delegate coding tasks to the local Cursor Agent CLI, with persistent per-workspace sessions that resume across calls.
Updated a month ago (2026-08-11 08:15 UTC)
12
MIT
pi-delegate-mcp
Coding Agents Code Analysis Autonomous Agents
sotola122
A
license
Not graded
quality
B
maintenance
Delegates bounded coding tasks from MCP clients to the Pi Coding Agent over stdio. Supports review, verification, implementation, and batch operations with long-running task polling.
Updated 18 days ago (2026-08-19 02:08 UTC)
MIT
chatgpt-deepseek-bridge
Coding Agents Agent Orchestration Autonomous Agents
zzzjjack
A
license
Not graded
quality
B
maintenance
Enables ChatGPT (or any MCP client) to delegate coding tasks to a local Hermes-backed agent with async job management, supporting read-only investigation, implementation, and continuation of sessions via secure MCP tunnel.
Updated 25 days ago (2026-08-12 03:59 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/guyiicn/pi-subagent'

If you have feedback or need assistance with the MCP directory API, please join our Discord server