Skip to main content
Glama

native_subagent_completed

Persists the terminal result returned by a native Codex subagent after wait_threads completes, recording status, result, or error for downstream task tracking.

Instructions

Persist the terminal result returned by a native Codex subagent after wait_threads completes.

Input Schema

NameRequiredDescriptionDefault
errorNo
resultNo
statusYes
task_idYes
lease_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered and the description's "Persist" is consistent with a write. Beyond that it adds almost nothing behavioral: no idempotency semantics (what happens if the same task_id/lease_id is persisted twice), no statement of which status values are terminal, and no error-path behavior despite an `error` parameter existing.

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?

A single front-loaded sentence with no filler, and the action verb leads. The only cost is the reference to a non-sibling tool name ("wait_threads"), which spends words on a pointer the agent cannot follow.

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?

This is a state-mutating persistence tool with 5 parameters, zero schema descriptions, a nested object parameter, and no output schema. One sentence cannot cover how task_id/lease_id are obtained, whether persistence is mandatory per subagent, or how it interacts with native_subagent_started/event — all of which an agent needs to call it 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?

Schema description coverage is 0% across 5 parameters, so the description must compensate and it does not. Only "result" and "status" are obliquely implied by "terminal result"; task_id, lease_id, and error are never explained, and the completed/failed/cancelled/blocked enum meanings are left entirely undefined.

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?

States a specific verb ("Persist") and a specific resource ("the terminal result returned by a native Codex subagent"), which distinguishes it from the streaming-style sibling native_subagent_event. However, it never contrasts itself with native_subagent_started/native_subagent_event explicitly, and it references "wait_threads," a tool that is not among the listed siblings (wait_tasks is), which muddies the picture.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase "after wait_threads completes" implies a trigger condition, so timing is at least hinted at. But there is no explicit when-not guidance, no statement that non-terminal progress should go to native_subagent_event instead, and no mention of prerequisites such as holding a valid lease_id.

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