Skip to main content
Glama
jordankzf

claude-subagents-mcp

by jordankzf
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

spawn_claude_agent

Spawn an independent Claude subagent for delegated tasks, receiving a returned ID to track progress while you continue your own work.

Instructions

Spawn an independent Claude subagent. Save the returned ID, continue your own work, then call wait_claude_agents directly. No listing step is needed. No shell or browsing tools.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskYes
modelNoOptional proxy model ID. Omit for configured default (claude-fable-5-1 unless changed). Use list_claude_models if needed.
max_stepsNo
task_nameNoShort human-readable task label.
workspaceNoAbsolute directory the agent may access. Omit for reasoning-only tasks.
max_tokensNoOutput ceiling, including thinking. Omit for automatic budget: 65536 at xhigh/max, otherwise 8192. Model limits apply.
request_idNoOptional unique request key; reuse after a transport failure to recover the same task, even if completed.
allow_writesNoEnable file creation/edits inside the workspace only when within the user-authorized task.
timeout_secondsNo
reasoning_effortNoOptional reasoning effort. Omit to inherit the configured default, adapted automatically for models without effort support. Explicit choices are honored or rejected clearly. default omits the provider effort parameter. Effective settings and any adjustment are returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden. It discloses that the agent is independent, that the call is non-blocking ('continue your own work'), that the lifecycle continues via wait_claude_agents, and that the agent has no shell or browsing tools. It does not mention potential file-write side effects, though allow_writes is documented in the schema.

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?

Four short sentences, each earning its place: purpose, workflow, a negative instruction about listing, and capability boundaries. The core purpose is front-loaded and there is no filler.

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 10 parameters and a rich schema, the description adequately covers the high-level lifecycle and behavioral constraints. The main gaps are the lack of an explicit output-shape statement beyond 'returned ID' and no direct comparison to ask_claude, but the task is still callable correctly with the provided schema and workflow.

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?

Schema coverage is only 70%, but the description contributes no parameter-level meaning at all. The undocumented parameters—task, max_steps, and timeout_seconds—receive no clarification in the description, and the existing schema descriptions must carry the entire burden.

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 opens with 'Spawn an independent Claude subagent,' stating a specific verb (spawn), resource (Claude subagent), and a key differentiator (independent). This clearly separates it from the sibling tools that wait, list, get, or cancel agents.

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?

It gives concrete workflow guidance: 'Save the returned ID, continue your own work, then call wait_claude_agents directly' and 'No listing step is needed.' It does not explicitly contrast with the synchronous ask_claude sibling, so it stops short of a full when-vs-alternatives explanation.

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

Deploy Server

Other Tools