Skip to main content
Glama
jordankzf

claude-subagents-mcp

by jordankzf

wait_claude_agents

Wait for the first of up to four Claude agents to finish or fail and return its result directly. Use saved cursors to avoid duplicate results; a timeout indicates work remains pending.

Instructions

Wait for the first of up to four specified Claude agents to finish or fail; returns its full result directly. No list/get cycle. Save returned cursors to avoid receiving the same result twice. Timeout means work remains pending.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorsNoPer-agent cursors returned by a previous wait.
agent_idsYes
timeout_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/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 only the first finished/failed agent's result is returned, that cursors prevent duplicate results, and that a timeout means work remains pending. It does not cover all edge cases, but these are meaningful behavioral traits beyond 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, information-dense sentences with no filler. Each sentence adds a distinct useful fact: purpose, result delivery, cursor guidance, and timeout semantics.

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?

For a tool with no annotations and no output schema, the description is strong: it explains what happens, what the caller should do with cursors, and what a timeout implies. It could mention explicit error/failure behavior in more detail, but the core usage is complete.

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 coverage is low, and the description compensates by explaining the up-to-four limit, cursor reuse semantics, and timeout meaning. It adds clarity beyond the raw parameter names, though timeout_seconds lacks explicit numeric behavior beyond 'work remains pending.'

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 begins with a specific action ('Wait for the first... to finish or fail') tied to a clear resource (Claude agents) and a concrete result ('returns its full result directly'). It differentiates itself from list/get polling by explicitly saying 'No list/get cycle.'

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 gives actionable usage guidance: save returned cursors to avoid duplicate results. The phrase 'No list/get cycle' implies this tool replaces polling. It lacks explicit 'when not to use' or named alternatives, but the intended context is clear.

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