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

With no annotations present, the description carries the full behavioral burden and does so well: it discloses blocking semantics, timeout behavior (returns current state rather than error), repeat-call safety, and that archived runs remain readable after reaping. These details are not visible in the schema or annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose, followed by behavior notes and a structured Args section. Every sentence adds operational value with no filler or repetition of the schema.

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

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

For a two-parameter polling tool with an output schema, the description covers the essential operational context: when to call it, what it does when the run is unfinished, repeat safety, and persistence of results. Nothing an agent needs to decide whether to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters, and it does: run_id is defined as the run to wait on with explicit provenance, and wait_seconds is explained as the maximum block time with sizing guidance for big tasks. This adds meaning well beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description leads with a specific verb and resource: 'Wait for a run to finish and return its result.' This clearly distinguishes glm_await from sibling tools like glm_list, glm_cancel, and glm_transcript, and the run_id provenance from glm_delegate/glm_continue makes its role in the workflow explicit.

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

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

It gives clear context for when to use the tool: after obtaining a run_id from glm_delegate or glm_continue, to block until completion. It also states that repeated calls are safe, which is useful polling guidance, though it does not explicitly name alternatives or state when not to use it.

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

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly states that the harness has no mid-turn cancel, that the child process is killed, that in-flight runs are reported as cancelled, that file edits persist, and that the session context cannot be resumed. This is exemplary transparency for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is tightly structured: a one-sentence purpose statement, a short behavioral detail block, and an args section. There is no filler or redundancy—each sentence adds essential information about what the tool does or what the agent should do afterward.

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

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

The description covers all key aspects of this session-ending operation: mechanism, effect on in-flight work, persistence of file edits, and the inability to resume. With an output schema present and a single parameter, no significant information is missing for an agent to decide whether and how to invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. The Args section ('agent_id: Agent to stop') gives the parameter a clear role and connects it to the tool's purpose. For a single parameter, this is sufficient, though it could have added where to find the ID (e.g., via glm_list).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Stop a subagent and release its runtime process.' It clearly distinguishes this from siblings like glm_delegate and glm_await, which handle creation and waiting, and even explains the mechanism (killing the child process) that makes this tool unique.

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

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

The description gives clear context for when to use the tool: when a subagent must be stopped and its runtime process released. It also provides critical post-cancel guidance—'start a new agent rather than continuing this one'—which prevents misuse. It does not explicitly name alternative tools, but the sibling set and the cancellation semantics make the use case obvious.

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

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

With no annotations provided, the description carries the full burden and delivers: it discloses that the child 'keeps the full context of its earlier turns,' that work is queued behind a mid-run agent, that omitting verification yields 'completed_unverified,' and that wait_seconds blocks with 0 returning immediately. These are non-obvious runtime behaviors an agent must know before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description front-loads purpose in the first sentence, follows with a dense behavior paragraph where every sentence earns its place, and closes with an Args list that maps exactly to the schema. The quoted example ('the migration you just wrote') adds value by showing the expected message style rather than padding.

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

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

The description covers what the tool does, when to use it, and all four parameters including session continuity, queuing, verification, and blocking semantics. An output schema exists, so the description need not enumerate return values, and the single referenced status ('completed_unverified') usefully bridges to that schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the Args section fully compensates by adding meaning the schema lacks: agent_id's provenance (from glm_delegate/glm_list), verification's role as a completion-proving command with a defined omission case, and wait_seconds as a blocking control where 0 returns at once. Every parameter receives semantics far beyond its bare title.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The lead sentence states a specific verb and resource: 'Send follow-up work to an existing subagent, in its original session.' The qualifiers 'existing' and 'original session' clearly distinguish it from the sibling glm_delegate, which creates new agents, so there is no ambiguity about what this tool operates on.

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

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

The description gives clear usage context: agent_id is sourced 'from glm_delegate or glm_list,' and the queuing note ('if the agent is mid-run, this message runs after it') tells an agent it can send follow-ups without waiting for the agent to become idle. However, it never explicitly states when not to use it or names alternatives such as glm_await for the waiting case, so it falls short of full explicit routing guidance.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses immediate return with agent_id and run_id, per-call process/session isolation, the child's inability to ask clarifying questions, and how the verification command is run and its exit code determines completed vs. completed_unverified. This is far beyond a minimal description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The most important behavioral facts are front-loaded before the parameter list, and every sentence earns its place. The parameter explanations are compact yet concrete, using examples and defaults rather than padding. Length is proportionate to the tool's complexity.

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

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

For a 7-parameter tool with no annotations, the description covers invocation behavior, parameter semantics, defaults, workspace configuration, return behavior, and verification semantics. Since an output schema exists, the description does not need to enumerate return fields; the agent has enough context to select and call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the Args section fully compensates by explaining every parameter: task requires acceptance criteria, verification is an executable shell command with examples, workspace resolves relative paths against the server workspace, instructions are prepended, model defaults to server config, name appears in glm_list, and wait_seconds blocks for up to that duration.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Start a new Claude Code subagent on a task.' It also distinguishes itself from the sibling glm_continue by noting that each call creates a fresh agent and that glm_continue is for existing agents. An agent can tell this is the creation tool, not a listing, waiting, cancellation, or transcript tool.

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

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

The description explicitly tells the agent to use glm_continue for work on an already-existing agent, and explains that wait_seconds controls immediate vs. blocking behavior. It does not explicitly contrast with glm_await or glm_cancel, but the core when-to-use guidance for creating a new subagent is clear.

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

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

With no annotations provided, the description carries the full burden. It discloses the operation is a read-only listing ('List'), the scope ('every subagent this server owns'), and the included data fields. This is sufficient for a non-mutating, zero-parameter tool, though it doesn't explicitly state 'does not modify subagents'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no redundant words. The verb and object come first, and the output fields are listed compactly. Every element earns its place.

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

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

For a zero-parameter read-only listing tool, the description is complete: it states the scope, the returned data, and the ownership boundary. The presence of an output schema means return structure is already specified, and siblings provide workflow context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no parameter ambiguity and the schema needs no embellishment. Baseline 4 applies: the description adds meaningful context about what the returned list will contain, even though no parameters exist to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('List'), a precise resource ('every subagent this server owns'), and the returned attributes (state, cost, run history). This clearly distinguishes it from sibling tools, which are all action verbs (delegate, await, continue, cancel, transcript) rather than listing operations.

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

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

The description makes the usage context obvious: call this when you need an overview of all owned subagents and their state/cost/history. It doesn't explicitly name alternatives or exclusions, but no sibling competes with listing, so the context is clear enough without explicit routing.

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

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

With no annotations, the description carries the full burden and does so well. It reveals that data is live while the run is ongoing, that only the tail is returned by default, and that raw returns an uncapped response. It implies a read-only inspection operation through wording like 'show' and 'returns.' Minor omissions like error behavior or pagination, but the core behavioral traits are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The summary sentence is front-loaded and concise. The subsequent detail paragraph and args list are clearly structured with no fluff. Every sentence adds useful information, and the format is easy to scan.

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

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

The tool has an output schema, so return-value details need not be repeated. The description covers the essential context: what the log contains, live behavior, the limit mechanism, and the raw option. Missing explicit failure semantics or auth requirements, but for a read-only inspection tool the provided information is complete enough for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates. It explains run_id as 'the run to inspect,' limit as the number of recent activity lines, and raw with a detailed rationale tying it to glm_delegate's distillation behavior. This adds meaning far beyond the bare type/default information in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Show what a subagent actually did during a run.' It clearly states the tool returns the tail of an activity log (tool calls, assistant messages, turn endings), distinguishing it from siblings like glm_delegate or glm_await. The raw parameter explicitly contrasts with glm_delegate's distilled version, further differentiating it.

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

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

The description gives concrete use cases: 'check progress on a long run, or to understand a failure.' It also explains when the raw parameter matters relative to glm_delegate's output. It does not explicitly say when not to use this tool or name sibling alternatives, but the provided context is enough to guide selection.

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