Skip to main content
Glama

List subagent invocations

list_invocations
Read-onlyIdempotent

Lists active and recently finished subagent invocations in chronological order, with metadata only. Use wait_agent or wait_any to read results.

Instructions

List this server's active invocations and finished ones not yet expired, oldest first.

Metadata only: no prompt, reply or tool data. events_seen tells whether the CLI has emitted any structured event. Active entries include phase; finished ones keep a fixed elapsed_ms and include a non-empty native session_id. Use wait_agent or wait_any to read results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
invocationsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.17.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already carry the safe-read profile (readOnly, idempotent, non-destructive, closed-world), but the description adds real behavioral context beyond them: metadata-only with no prompt/reply/tool data, oldest-first ordering, expiry of finished entries, and lifecycle semantics (active entries carry phase; finished ones hold a fixed elapsed_ms and a non-empty session_id). Field-by-field notes partially overlap with the output schema, keeping this short of a 5.

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?

Three tight sentences plus a routing clause; scope and ordering are front-loaded, and every sentence adds information (scope, data exclusions, field semantics, alternative routing) with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return values, yet it still supplies the scope, ordering, expiry behavior, and data-exclusion guarantees an agent needs to call and interpret this correctly. Nothing material is missing.

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?

The tool takes zero parameters, so the schema imposes no semantic burden and the baseline is 4. The description correctly spends no words on parameters.

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?

Specific verb (List) plus resource (this server's invocations) with a precise scope: active entries plus finished ones not yet expired, ordered oldest first. It is clearly separable from wait_agent/wait_any, which are for reading results rather than enumerating invocations.

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 final sentence explicitly routes the agent: 'Use wait_agent or wait_any to read results,' which implies list_invocations is for metadata enumeration only. It gives the alternative and the condition that selects it, but never states a positive when-to-use case or any exclusion for this tool itself.

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