get_draft

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

With no annotations provided, the description carries the full behavioral burden for this read operation. It conveys that it is a non-mutating read and that omission of version yields the latest, but says nothing about behavior when the draft or seed does not exist, permission requirements, or what is returned.

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?

A single short sentence, front-loaded with the verb and resource, with no filler. Its brevity is efficient, though it flirts with under-specification rather than achieving true conciseness with completeness.

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 3-parameter tool with zero schema description coverage, no annotations, and no output schema, the definition is too thin. An agent cannot determine what seed_id and channel mean or what happens on a missing draft, so key call-shaping information is absent.

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, yet it explains only the optional version parameter's default semantics. seed_id and channel are left entirely undefined, including whether seed_id identifies the draft or its origin and how channel constrains the lookup.

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 pairs the specific verb "read" with the resource "draft version" and clarifies the default behavior when version is omitted. It does not, however, distinguish this tool from plausible siblings such as get_draft_kit or list_drafts, so the agent must infer the boundary itself.

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?

There is no when-to-use guidance beyond the verb itself: nothing says when to fetch a single draft versus listing drafts, or when to use get_draft_kit instead. The parenthetical about version defaulting is the only situational hint, and it explains a parameter rather than tool selection.

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