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

Annotations already establish the safety profile (non-readOnly, openWorld, non-idempotent, non-destructive), and the description adds real side-effect detail beyond that: Sinatra assigns/labels the issue and may push a branch and open a pull request. It also discloses where the conversation lives and how to track progress, though it says nothing about auth requirements or failure conditions.

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?

Two dense sentences, front-loaded with the core action, then side effects, then conversation routing. Nearly every clause earns its place; only 'as if you'd assigned it to Sinatra yourself' mildly restates the opening.

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, so the description's note that progress surfaces via list_tasks fills the reporting need, and the annotations cover the safety profile. Between description, schema, and annotations an agent has what it needs to call this 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 80%, so the schema already documents id, repo, number, and workspace_id well. The description adds only the implication that the referenced issue is 'existing,' which is marginal field-level value over the schema.

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 names a specific verb (delegate/hand off) and resource (an existing Linear or GitHub issue) and even names the actor it is handed to (Sinatra). An agent can distinguish this from siblings like start_task or search_tickets 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?

It gives clear context for use (an existing issue that you want Sinatra to take over) and explicitly rules out two siblings, noting follow_up and get_messages don't apply here. It still doesn't contrast with start_task, the closest sibling, so the routing guidance is strong but not exhaustive.

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