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

With no annotations provided, the description carries the behavioral burden and does well: it discloses that the operation is non-sending, that it executes in the background, and that the new text will NOT be in the response — the single most important fact for correct orchestration. It omits permission requirements, whether repeated calls compound changes, and failure behavior, which keeps it short of a 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?

Front-loaded with purpose, then the critical async caveat, then per-argument notes — good ordering with no wasted prose in the body. The trailing "### Responses: **200**: Successful Response ... Content-Type: application/json" block is HTTP boilerplate that adds nothing for an agent and slightly dilutes the signal.

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 two-parameter, no-output-schema, no-annotation tool, the definition covers the essentials: what it mutates, that it does not send, and exactly how to retrieve the result. Remaining gaps are secondary — whether the rewrite overwrites the existing draft in place, and whether re-invoking stacks changes.

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 must compensate, and it does: it identifies the 'draft_' handle prefix and its provenance (list_drafts), and characterizes the instruction semantically with three concrete examples of the expected free-form style. That is meaningfully more than the bare string types in 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?

States a specific verb and resource — "Rewrite a connection-note draft with an instruction" — and immediately bounds the outcome with "Does not send." The phrase "connection-note draft" distinguishes it from the sibling rewrite_reply_draft, rewrite_comment_draft, and rewrite_content_draft without the agent needing to open their schemas.

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 operational context: the rewrite is asynchronous, so the caller must follow up with get_draft_detail or list_drafts, and the handle is sourced from list_drafts. It does not explicitly say when to prefer this over edit_comment_draft-style manual editing or when to pick the sibling rewrite_* tools, but the resource scoping makes the choice largely self-evident.

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