get_draft

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that content and attachment data are included in the result, which is useful, but it says nothing about behavior for an unknown or deleted draftId, or whether attachments are inlined versus referenced.

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?

One front-loaded sentence with no filler; the return payload is stated before any hypothetical detail. It is arguably too terse for the surrounding draft CRUD family, but nothing in it is wasted.

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 single-parameter read with no output schema, the description is minimally sufficient: it says what comes back, which is the main thing an agent cannot infer. It stops short of covering the not-found case and the local-versus-remote distinction that the sibling set makes relevant.

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 sole parameter draftId carries only a uuid format and pattern in the schema. The description never explains that draftId is the local draft identifier or where to obtain it, but with a single self-evident ID parameter this is a minor gap rather than a blocking one.

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 ('Read') and resource ('a local draft') plus the payload the caller gets back ('content and attachment data'). The word 'local' distinguishes it from a server-side message fetch, though it never names list_drafts or get_message explicitly.

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?

Usage is only implied: 'local draft' plus a required draftId suggests fetching one known draft rather than enumerating, which is what list_drafts is for. There is no explicit when-to-use statement, no exclusions, and no mention of how this differs from get_message or create_draft/update_draft.

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