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

Annotations already mark readOnly/idempotent, and the description adds substantial behavioral detail: output encoding (base64 PDF), associated metadata, rendering scope only for fields with valid coordinates, exclusion of invalid fields from the PDF, draft-status/expiry constraints, and Bearer-token authentication. No contradiction with annotations.

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?

The description is compact and every sentence earns its place: output format, sibling routing, rendering edge case, and prerequisites/auth. It is front-loaded and gives the agent the most decision-relevant information first.

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?

Even with no output schema, the description fully explains return values (base64 PDF, filename, size), rendering edge cases, usage conditions, and authentication. The single required parameter is fully documented, and the sibling-routing guidance is explicit, making the description sufficient for correct invocation.

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 coverage is 100% and the only parameter, draftId, is already clearly described in the schema as 'Unique identifier of the draft to preview'. The description does not add syntax, format, or parameter-specific nuances beyond this; its added text is about the draft/resource behavior, not the parameter semantics.

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?

Clearly states the tool returns a PDF preview with signature fields rendered at their configured coordinates, as an embedded resource plus filename and size metadata. It also explicitly contrasts with get_draft_file_url, making the purpose and distinction unmistakable.

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?

Explicitly says when to use this tool (when the MCP client can render PDFs inline) and when to use get_draft_file_url instead (when only clickable links are supported). It also establishes prerequisites—draft must still be status draft and must not be expired—so an agent can pre-check validity before invoking.

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