Skip to main content
Glama
deenesjakoruzh
guyiicn

pi-subagent

by guyiicn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
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）がいつ委任するかを決定し、自己完結型のタスクを発火し、結果を収穫します。1つのPiプロセス = 1つの分離されたサブエージェント実行です。

  • プロセス分離 — 各委任は1つの pi -p 子プロセスを生成します。Pi がクラッシュしても、その実行のみに影響します。

  • 完全セッションベース — すべてのタスクは名前付きセッション（例: feat-auth）にバインドされ、後続の呼び出しは自動的に継続されます。

  • 同期 / 非同期 — デフォルトは async（ホストのツール呼び出しタイムアウトを回避）。pi_status のロングポーリングで収穫します。

  • スケジュール可能 — pi_plan は純粋な5段階の決定関数（reject / capacity / reuse / modify / mode）で、完全にユニットテストされています。

  • ユニバーサル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+)     │
                   └─────────────────────┘

明確な境界を持つ3つのレイヤー: ツールレイヤー（MCPスキーマ + plan() 純粋関数） / セッションレジストリ（状態 + 永続化 + 編集） / ランナー（pi の生成、NDJSONの解析、プロセステーブル）。

ツール

ツール

目的

pi_plan

判断: 委任すべきか、同期/非同期、セッション数

pi_delegate

タスクをディスパッチ（デフォルトは非同期、新しいセッションはハンドシェイクを待つ）

pi_status

実行結果の収穫（ロングポーリング）

pi_session_list

セッション一覧（pi_plan が必要とする完全なセットの場合は cwd を省略）

pi_session_snapshot

1つのセッションを検査

pi_session_fork

別のパスを試すためにセッションを分岐

pi_kill

実行を中断

pi_task_create

マルチステージタスクを作成（ホストは最初に _plan-draft.md を書く）

pi_task_plan

プランのドメインレビューをディスパッチ（pi_status で収穫、判定は自動解析）

pi_task_stage_run

1つのステージを実行: 同期（結果を待つ）または非同期（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 になり、決定パネルが表示されます（retry_with_new_hint は promptHintOverride でサポート）。

再起動リカバリ: 同じ 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 のセッションファイルはデフォルトの場所を使用します（プロジェクトを汚染しません）。

  • 非同期デフォルト + ハンドシェイク — 新しいセッションは、戻る前に Pi の session イベントを待ちます（sessionStartTimeoutMs 付き）。これにより、ホストは常に実際の piSessionId を取得します。

  • マルチステージスケジューラ — plan() は reject → capacity → reuse → modify → mode の順で、修飾子は最初に一致するのではなく積み重なります（レビューラウンド1からの教訓）。

  • 進捗の編集 — ツール結果は、保存前にトークン/キーが切り詰められ、スクラブされます。

ステータス

実装済み、140のテストが合格。まだ npm に公開されていません — tsx でソースから実行します。

ライセンス

MIT

Available Tools

7 tools
pi_delegateC

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

NameRequiredDescriptionDefault
cwdNo
goalNo
modeNo
promptYes
sessionYes
constraintsNo
runTimeoutMsNo
allowUnknownToolsNo

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

NameRequiredDescriptionDefault
runIdYes

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

NameRequiredDescriptionDefault
cwdYes
taskYes
fanoutNo
estComplexityNo
preferredModeNo

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

NameRequiredDescriptionDefault
toYes
fromYes

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

NameRequiredDescriptionDefault
cwdNo

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

NameRequiredDescriptionDefault
sessionYes

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）

NameRequiredDescriptionDefault
runIdYes
waitTimeoutMsNo

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.

  1. 7 tool updatesv0.1.0
    • 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 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

Related MCP Servers

  • pokeclaw

    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.
    4
    MIT

  • pi-agent-mcp

    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.
    2 npm
    -

  • agentmux

    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.
    17
    13 npm
    Apache 2.0