subagent-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SUBAGENT_MCP_MAX_CONCURRENT | No | Maximum number of agents that may run concurrently. At most maxConcurrent agents run at once (default 12, or SUBAGENT_MCP_MAX_CONCURRENT). | 12 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| experimental | {
"claude/channel": {}
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| spawn_agentA | Delegate implementation, research, or exploration work to a fresh subagent (Claude Code, Codex, OpenCode, Antigravity, or Cursor). Mirrors the native Agent tool: the child starts with no parent context, blocks by default until it finishes or needs your approval, and returns a resumable agent_id. The result always includes a human-memorable |
| send_messageA | Resume a completed agent by ID or name, preserving its full history. Blocks like spawn_agent. Codex resumes replay the whole thread with no prompt cache: the result includes a warning, and a resume after a long idle (default 30 minutes, codexResumeIdleSeconds in models.yaml) is refused unless allow_expensive_resume is true. |
| list_agentsB | List agents tracked by this host, including ones restored after a reconnect, with their lifecycle state and human-memorable name. Refer to agents by name in later tool calls. Also reports timeout_seconds, the concurrency cap, how many agents are active, and how many spawns are waiting. |
| list_agent_configsC | Discover callable configs, source files, pinned options and backend capabilities |
| wait_for_agentsB | Event-driven join; returns on any/all completion, approval, or timeout without stopping agents. Maximum 60 seconds. |
| get_agent_resultB | Retrieve persisted results and paginated turn history after reconnect or resume |
| cleanup_worktreeB | Remove an inactive, clean managed worktree, retaining its branch for review |
| stop_agentsC | Cancel queued tasks and interrupt agents by IDs or group. Supply agents or group_id. |
| stop_agentA | Interrupt a running or approval-parked agent and signal its whole process group, so shells and builds it spawned (cargo, check_task) die with it. Idempotent. |
| resolve_approvalA | Decide a parked approval request from spawn_agent/send_message's needs_approval result. Blocks and returns the agent's next state (completed, another needs_approval, or running). |
| get_agent_eventsA | Buffered normalized event log for an agent, for background polling. Reliable floor for progress. The response identifies the agent by both |
| list_modelsA | Config-sourced model roster plus per-backend usage counters (spawns, resumes, turns, failures, timeouts, tokens, and cost) and, when models.yaml sets allowances, how much of each allowance is left. Also reports the concurrency cap, the number of active agents, and how many spawns are waiting for a slot. |
| record_outcomeB | Record your subjective verdict on a completed delegation, for future routing decisions. |
| add_noteC | Append a free-form delegation note to project or user routing memory. |
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 14 tools
Most tools have clearly distinct purposes across the subagent lifecycle: spawning, messaging, listing, polling events, retrieving results, waiting, approving, and cleanup. The main possible confusion is between stop_agent and stop_agents, but their descriptions distinguish single-agent interruption from batch/group cancellation; list_agents versus list_agent_configs is also distinguishable but close enough to require attention.
All tools use consistent snake_case verb_noun naming, such as spawn_agent, send_message, get_agent_events, list_agents, stop_agent, and cleanup_worktree. The singular/plural distinction in stop_agent and stop_agents is a deliberate scope difference rather than a naming inconsistency.
Fourteen tools is well within the appropriate range for a subagent orchestration server and each tool maps to a meaningful lifecycle operation. There is no obvious padding or missing core action at the count level.
The set covers the full subagent lifecycle: discovery, spawning, resuming via messaging, event polling, waiting, result retrieval, approval resolution, stopping, cleanup, and routing memory. Listing models and configs plus recording outcomes and notes also supports operational decision-making and observability.