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

Adds substantial behavior beyond annotations: cost model and BYO key/wallet fallback for autonomous agents, free deterministic workflow runs, possible no-op/skipped outcomes reported as actionable errors, and success returning a new run id. This is exactly the context an agent needs for a non-idempotent, costly-by-default action.

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?

Front-loaded with the core action, then cost, no-op behavior, return value, and tier. The single dense paragraph is efficient, though the no-op explanation is slightly verbose and could be tightened without losing meaning.

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?

Complete for a complex tool: covers cost, failure/no-op conditions, success return, follow-up tool, and tier gating. Since an output schema exists, the description does not need to enumerate return fields and still usefully names the run id.

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 coverage is 100%, so baseline is 3. The description adds meaningful target semantics by stating it must be one of the caller's own standing agents and by explaining how agent_type affects cost and execution, going beyond the simple schema label.

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?

States a specific verb and resource ('Fire one of the caller's own standing agents now') and clarifies the key scope distinction ('out of band from its schedule') that separates it from schedule_task and get_agent_run. An agent can identify the operation without opening the schema.

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?

Provides strong operational context: when to run now versus scheduled, that get_agent_run should be used afterward, and that tier requirements apply. It does not explicitly name run_workflow as the alternative for workflow agents, but it does distinguish autonomous versus workflow cost behavior clearly 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.