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 richly: model substitution is reported as model_substitution, tool narrowing is inherited and further restricted to the calling run's allowlist with tools_not_permitted, child-kind callers drop shell/browser/secret HTTP, no-calling-run keeps target tools, and budget exhaustion refuses with agent_budget_exceeded while leaving the running turn alone. That is exactly the pre-call behavioral context an agent needs.

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 one-line purpose, then trades detail for correctness; every clause about substitution, allowlists and budget maps to a real decision point. Sentences are long and jargon-dense (e.g. 'Keeps the run's tools narrowing and agent record'), costing a little readability.

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 complex nested-run tool with no annotations, the description covers the behaviors that matter (model re-check, tool inheritance/allowlist, budget refusal, running turn preserved), and return values are covered by the existing output schema, so nothing essential 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 100% and the schema already explains prompt, run_id (TeamShared UUID or Cursor run-… id), cursor_agent_id (used when run_id is omitted) and the agent label. The description references 'a run bound to an agent' but does not clarify precedence or when to prefer cursor_agent_id over run_id, so it adds little beyond the schema — 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 first sentence names a specific verb and resource — 'Enqueue a follow-up prompt on an existing TeamShared Cloud Agent' — and the word 'existing' separates it from agent_run_start (creating a new run). An agent can pick between the two siblings without opening either 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?

The 'existing ... agent' framing plus repeated contrasts to agent_run_start and 'a nested start' make the when-to-use context clear. It never states the negative case outright (e.g. 'to create a new run use agent_run_start instead'), so it stops short of full routing guidance.

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