draft_preview

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

No annotations exist, so the description carries the full burden. It does disclose genuine domain behavior by explaining per-platform constraints (Substack = paste pack, beehiiv = draft-only), which is useful context beyond the name. It says nothing about whether the call is read-only, whether it triggers rendering work, or about cost/latency, leaving meaningful gaps for an unannotated tool.

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 dense sentence with no filler, and the core payoff (per-platform previews plus diffs) is front-loaded. The parenthetical about platform constraints is worth its length, though the jargon ('adaptation diff', 'paste pack') is left undefined.

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 one-parameter read tool with no output schema, the description does sketch the return payload (rendered previews and diffs), which the schema cannot. It stops short of describing structure, size, or how many platforms appear, so an agent still cannot anticipate the response shape.

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% and the single parameter draft_id appears nowhere in the description. The argument is largely self-explanatory from its name, but nothing explains whether it accepts an ID versus a slug, or what happens with an unknown or unapproved draft.

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 the specific artifact produced: per-platform rendered previews plus adaptation diffs against the canonical draft. That distinguishes it clearly from draft_create, draft_approve, and syndicate_drafts. It never states the operation as a verb (fetch/generate), reading more like a description of output than an action, which keeps it from a 5.

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?

'The review artifact' faintly implies use at the review stage, but there is no explicit when-to-use, no prerequisite such as an existing draft_id, and no comparison to draft_approve or syndicate_drafts. An agent must infer the call site from the noun phrase alone.

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