cursor_followup

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

With no annotations, the description carries the full burden and does well: it discloses that a NEW run is started, that the old run_id becomes stale, that a run_id is returned for polling, and that concurrent calls fail with 'agent is busy'. It stops short of stating permissions/auth or confirming the mutation/reversibility profile, so 4 rather than 5.

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?

Three tight, front-loaded statements: what it does, what it returns and how to poll it, and the guard condition. No filler; every sentence 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?

No output schema exists, but the description compensates by explaining the return (run_id for polling) and the stale-run caveat. Usage context is complete; the only shortfall is the absence of any parameter-level detail for a 0%-coverage 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%, so the description should compensate, but it never explains agent_id or prompt beyond their self-evident names. The 'prompt' meaning (the follow-up text) is inferable and the run_id detail relates to output rather than input, so this is minimally viable rather than strong.

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?

Specific verb ('Send a follow-up prompt to an agent') plus resource (agent), and it immediately clarifies that this starts a NEW run rather than continuing the old one. This distinguishes it cleanly from cursor_launch and cursor_status without opening any 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?

Explicitly states the precondition ('Only call when the previous run is terminal') and the failure mode if violated ('agent is busy'), then names the alternative to use first ('poll cursor_status'). This is textbook when-to-use/when-not-to guidance.

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