Render a message without sending it

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

Adds substantial behavior beyond the annotations: the no-network guarantee ('without connecting to anything'), full validation parity with send (allowlist, recipient limit, attachment policy, size limit), and the security-relevant output behavior (attachment payloads summarised by name, size and digest rather than printed). The readOnlyHint and idempotentHint annotations are consistent — no contradiction.

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?

Three dense sentences, each earning its place: core behavior, validation parity and workflow purpose, then output summarization caveat. The most decision-relevant fact (does not send) is front-loaded. No redundancy with the title or annotations.

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?

Complete for a complex 10-parameter tool with an output schema and full annotations. It covers what happens (preview built, checks run, headers/bodies returned), what does not happen (no connection), why to use it (pre-approval), and the attachment output caveat. The output schema covers return values and the rich parameter schema covers inputs, so nothing an agent needs to select and invoke correctly is missing.

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%, so the schema fully documents all 10 parameters. The description adds some contextual reinforcement by naming the checks that constrain parameters (recipient limit, attachment policy, size limit) and the digest summarization that affects how attachments appear in output, but it does not add per-parameter meaning. Baseline 3 is appropriate given full schema coverage.

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: 'Builds exactly the message send_mail would build and returns its headers and bodies, without connecting to anything.' This clearly distinguishes it from actually sending (send_mail) and from the siblings (validate_recipients, test_connection), which serve different purposes. The title reinforces the same meaning.

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?

Provides explicit when-to-use context: 'this is the way to find out whether a message is acceptable before asking a human to approve it.' It also signals that it subsumes validation tasks by stating every send-time check runs here. However, it does not explicitly contrast with the listed siblings or state when-not-to-use, so the routing guidance is clear but not exhaustive.

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