glm_delegate

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.