de en es ja ko ru zh

pi-subagent

Name: pi-subagent
Author: guyiicn

by guyiicn

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

pi-subagent

Pi CLI(@earendil-works/pi-coding-agent)을 프로그래밍 가능한 코딩 서브 에이전트로 전환하여, 모든 MCP 호스트(ZCode, Claude Code, Cursor 등)가 작업을 위임하고, 세션을 추적하고, 프로세스를 종료할 수 있게 합니다.

pi-subagent는 pi -p --mode json을 7개의 구조화된 도구로 감싸는 경량 MCP 서버입니다: 작업 위임, 결과 수집, 스케줄링 결정, 명명된 세션 관리, 실행 중단. 프로세스 격리, 완전 세션 기반, 동기/비동기 이중 모드.

왜 필요한가

Pi는 최소한의 터미널 코딩 에이전트입니다. 이 프로젝트는 Pi에게 방법론을 가르치는 대신, Pi를 위임 가능한 작업자로 취급합니다: 호스트 에이전트(ZCode / Claude Code)가 언제 위임할지 결정하고, 자체 포함된 작업을 실행하고, 결과를 수집합니다. 하나의 Pi 프로세스 = 하나의 격리된 서브 에이전트 실행.

프로세스 격리 — 각 위임은 하나의 pi -p 자식 프로세스를 생성합니다. Pi가 충돌해도 해당 실행에만 영향을 미칩니다.
완전 세션 기반 — 모든 작업은 명명된 세션(예: feat-auth)에 바인딩됩니다. 이후 호출은 자동으로 계속됩니다.
동기 / 비동기 — 기본값은 async(호스트 도구 호출 시간 초과 방지). pi_status 롱폴링으로 수집.
스케줄 가능 — pi_plan은 순수 5단계 결정 함수(거부 / 용량 / 재사용 / 수정 / 모드)이며, 완전히 단위 테스트됨.
범용 MCP — 모든 표준 MCP 클라이언트가 로드할 수 있습니다.

Related MCP server: pi-delegate-mcp

아키텍처

┌─────────────────────────────────────────────────────────────┐
│  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+)     │
                   └─────────────────────┘

명확한 경계를 가진 세 개의 계층: 도구 계층(MCP 스키마 + plan() 순수 함수) / 세션 레지스트리(상태 + 영속성 + 편집) / 러너(pi 생성, NDJSON 파싱, 프로세스 테이블).

도구

도구	목적
`pi_plan`	결정: 위임 여부, 동기/비동기, 세션 수
`pi_delegate`	작업 전달(기본 비동기, 새 세션은 핸드셰이크 대기)
`pi_status`	실행 결과 수집(롱폴링)
`pi_session_list`	세션 목록(`pi_plan`이 필요로 하는 전체 집합을 위해 `cwd` 생략)
`pi_session_snapshot`	단일 세션 검사
`pi_session_fork`	다른 경로를 시도하기 위해 세션 분기
`pi_kill`	실행 중단
`pi_task_create`	다단계 작업 생성(호스트가 먼저 `_plan-draft.md` 작성)
`pi_task_plan`	계획의 도메인 검토 전달(`pi_status`로 수집, 판정 자동 파싱)
`pi_task_stage_run`	한 단계 실행: 동기(결과 대기) 또는 비동기(runId 반환)
`pi_task_stage_collect`	비동기 단계 실행 수집, 자동 판정 및 재전달(최대 3회), 그 외 수동
`pi_task_list`	작업 목록(taskId / status로 필터링)

검토 루프: pi_task_plan 후 pi_status(runId)로 수집합니다. 실행이 완료되면 서버는 검토 실행임을 감지하고 _plan-reviewed.md를 파싱하여 planVerdict / planReviewedPath를 작업에 저장합니다. 단계 프롬프트는 자동으로 검토된 계획과 통과된 의존성 단계의 출력 파일을 포함합니다.

비동기 단계: pi_task_stage_run에 mode: "async"를 전달하면 전체 실행 동안 도구 호출을 차단하지 않습니다(MCP 호스트가 짧은 도구 시간 초과를 적용할 때 권장). pi_task_stage_collect(taskId, stageId)로 수집합니다. 실패한 시도는 새 세션 이름으로 재전달되어 기록 오염을 방지합니다. 3회 실패 후 단계는 manual이 되며 결정 패널(promptHintOverride를 통한 retry_with_new_hint 지원)이 표시됩니다.

재시작 복구: 동일한 taskId로 pi_task_create를 다시 실행하면 충돌 대신 병합됩니다. 출력 파일이 이미 존재하고 검증을 통과한 단계는 자동으로 passed로 표시되므로, 중단된 작업은 tasks.json을 수동 편집하지 않고 재개할 수 있습니다.

세션 모델

각 세션은 사람이 읽을 수 있는 이름 + Pi의 UUID + cwd + goal을 가집니다.
첫 번째 pi_delegate가 세션을 생성합니다(goal 필수). 이후 호출은 자동으로 계속됩니다.
레지스트리는 ~/.pi-subagent/registry.json에 영속화됩니다(원자적 쓰기, 재시작 시 중단된 running 레코드는 error로 수정).
동시성 상한: 4개의 실행 중인 런. 단일 세션은 동시에 실행되지 않습니다.
작업은 ~/.pi-subagent/tasks.json에 영속화됩니다(원자적 쓰기, 재시작 시 실행 중인 단계는 failed(interrupted_by_restart)로 수정).

설치

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

전제 조건: pi CLI가 설치되어 있고(npm i -g @earendil-works/pi-coding-agent) PATH에 있어야 합니다.

MCP 호스트 구성

MCP 클라이언트 구성에 추가:

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

선택적 환경 변수:

PI_SUBAGENT_REGISTRY — 레지스트리 경로(기본값 ~/.pi-subagent/registry.json)
PI_BIN — pi 실행 파일 재정의(테스트에서 사용)

테스트

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

테스트는 가짜 pi(test/fixtures/fake-pi.sh)를 사용하며 다음을 다룹니다: 비동기/동기, 시간 초과, 종료, 세션 생성 실패, 다중 대기자, 진행 상한, 스케줄링 규칙(테이블 기반 + 100회 반복 속성 테스트), 레지스트리 영속성, 편집 등.

프로젝트 구조

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

설계 및 프로세스

이 프로젝트는 협업 설계 + 구현 전 4차례의 외부 검토를 거쳤습니다. 사양과 계획은 docs/ 아래에 커밋되어 있습니다:

docs/design.md — 전체 설계 사양(아키텍처, 도구 계약, 오류 처리, 스케줄러 규칙, 테스트 전략). 모든 계약은 검토 노트(R1–R4)로 추적 가능합니다.
docs/implementation-plan.md — 19개의 TDD 작업(실패 테스트 작성 → 구현 → 통과 → 커밋).

모든 주요 설계 결정은 실제 pi -p 출력 프로빙과 외부 검토에 기반합니다:

cwd ≠ 세션 저장소 — spawn({ cwd })는 작업 디렉터리를 제어합니다. Pi의 세션 파일은 기본 위치를 사용합니다(프로젝트를 오염시키지 않음).
비동기 기본 + 핸드셰이크 — 새 세션은 sessionStartTimeoutMs로 Pi의 session 이벤트를 기다린 후 반환하므로 호스트는 항상 실제 piSessionId를 얻습니다.
다단계 스케줄러 — plan()은 거부 → 용량 → 재사용 → 수정 → 모드 순서이며, 수정자는 첫 번째 일치가 아닌 누적됩니다(검토 1차에서 얻은 교훈).
진행 편집 — 도구 결과는 저장 전에 잘리고 토큰/키가 제거됩니다.

상태

작동하는 구현, 140개의 통과 테스트. 아직 npm에 게시되지 않음 — tsx로 소스에서 실행.

라이선스

MIT

Available Tools

7 tools

pi_delegateC

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

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

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

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

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 用）

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 详情

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）

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.

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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.8/5.0

Scored 2026-07-01 07:25 across 7 tools

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.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Related MCP Connectors

ReasonOAuth
io.github.reason-machines
Start and manage Reason cloud coding agents, projects and sessions from any MCP client.
Coding Agents Agent Orchestration Autonomous Agents
1
https://mcp.reasonmachines.com/mcp
Node CommandOAuth
io.github.huseyincig
Remote MCP server exposing your Node Command fleet (files, shell, processes, browser) to AI hosts.
File Systems Shell Access Browser Automation
1
https://mcp.nodecommand.app/mcp
Roamer MCPOAuth
com.mathismeadows
Hosted MCP server and Agent Skills for specs, engineering threads, and project memory.
Agent Orchestration Developer Tools Project Management
1
https://roamer-mcp.mathismeadows.com/mcp
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
https://api.ai.tv/mcp

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 5 months ago (2026-06-08 12:59 UTC)
4
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 2 months ago (2026-08-19 02:08 UTC)
MIT
pi-agent-mcp
Coding Agents Agent Orchestration Autonomous Agents
a809384377
F
license
Not graded
quality
B
maintenance
Enables MCP hosts like Claude Code and Codex to spawn, manage, and interact with persistent, reusable Pi coding-agent sessions, supporting task dispatch, status checks, and session lifecycle control.
Updated 2 months ago (2026-08-22 06:12 UTC)
2 npm
-
agentmux
Autonomous Agents Agent Orchestration Developer Tools
seaweedsoup98
A
license
B
quality
B
maintenance
Enables any MCP host to delegate work to multiple coding-agent CLIs such as Codex, Claude Code, and Antigravity as subagents, preserving native sessions and supporting team-based supervision and agent-to-agent messaging.
Updated a month ago (2026-09-22 04:11 UTC)
17
13 npm
Apache 2.0