agent_lifecycle

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

No annotations are provided, so the description carries the full behavioral burden. It never states whether pause is durable or reversible, whether cancel_tool_call aborts only the current tool call or the whole run, or what permissions/state changes are involved for these mutation actions.

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?

It is a single short fragment with no waste, but the 'Extended:' prefix is cryptic noise and the terseness here reflects under-specification rather than efficient information density.

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 multi-action mutation tool with no annotations and no output schema, the description omits everything an agent needs: action-specific behavior, side effects, and expected results. Only the schema's parameter names carry the semantics.

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 100%, so the schema already documents bcId, runId, action, and toolCallId including which action each applies to. The description merely repeats the action enum values already present in the schema and adds no format or constraint detail, matching the baseline 3.

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 enumerates the four lifecycle actions but never names the resource or states the overall purpose in a verb+resource form — the agent must infer 'control agent execution state' from the tool name. It also does not distinguish this from siblings like cancel_run or steer_agent, which overlap with pause/cancel semantics.

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?

There is no when-to-use guidance, no prerequisites, and no routing to alternatives such as cancel_run for termination or steer_agent for redirection. An agent is left to guess which of these overlapping sibling tools applies.

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