PostalForm

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

Annotations only declare the write/safety profile, so the description earns credit for adding real behavior: idempotent retry with the same checkout and token, reuse of existing authorized/processing/paid payments, and instruction to follow the returned status and messages. It does not discuss auth requirements, rate limits, or failure modes beyond interruption.

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?

Four dense sentences, all of which carry actionable information, with the preconditions and identifier mapping front-loaded. No filler, though the sentences are long enough that key constraints compete for attention.

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 write tool with nested objects and an output schema, the description covers preconditions, idempotency, reuse of existing payments, and where to read the outcome. What remains thin is the distinction from sibling payment tools, which the description never addresses.

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 baseline is 3, but the description adds genuine meaning: it maps the order ID onto checkout_session_id, states a shared payment token (spt_...) is acceptable, and warns against resending the document or addresses. It does not further clarify the nested buyer/billing_address shapes, which the schema already covers.

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: pay/finalize an already-prepared checkout session with a payment token. It clearly scopes the tool to the post-approval step, though it never names the sibling pay_order it must be distinguished from. Minor ambiguity in 'Pass the order ID as checkout_session_id' blurs resource naming slightly.

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?

Gives a clear triggering condition ('after the buyer approves the prepared order and total') and an explicit do-not ('do not resend the document or addresses'), plus retry guidance on interrupted requests. It stops short of naming an alternative tool or stating when this should not be used instead of pay_order.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the safety profile is partly known; the description adds the crucial clarification that draft creation never pays and that payment happens later via a separate call, plus per-protocol return shapes (PDF preview, MPP challenge). It does not disclose idempotency behavior (despite a request_id field) or draft expiry/rate limits, which would have pushed this higher.

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, front-loaded with what the call produces and then the branch conditions, with no filler. Minor redundancy: 'Draft creation never pays' restates the same guarantee already embedded in the payment_protocol schema description.

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 23-parameter, nested-object mutation tool with an output schema, the description covers the highest-risk unknowns — whether it charges, what it returns, and which follow-up tool completes each payment path. It leaves the field/attachment/address mechanics and idempotency entirely to the schema, which is thin at 17% coverage, so it is strong on workflow but not fully complete.

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 only 17% across 23 parameters, so the description must carry the load, yet it explains only payment_protocol, buyer_email and the returned order_id. The high-impact parameters — slug (which workflow form), fields, attachments, request_id (idempotency), address_type enums and the deprecated use_workflow_recipient — receive no descriptive meaning in either place.

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 ('Prepare a supported workflow form for mailing') and immediately describes the output artifacts (order ID, total, checkout URL, checkout session). It also scopes the tool against siblings by naming create_machine_order for x402, making it distinguishable without opening any schema.

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 routes the agent across downstream alternatives with conditions: complete_checkout with a Stripe shared payment token after buyer approval, hosted checkout URL presentation otherwise, payment_protocol=mpp plus buyer_email for MPP followed by postalform.pay_order, and postalform.create_machine_order for x402. The only gap is that it doesn't explicitly contrast with create_order_draft/create_letter_order_draft, but 'workflow form' scoping covers that intent.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, but the description adds material traits beyond them: 'Draft creation never pays' clarifies that this write tool does not charge, and it enumerates the returned artifacts (order ID, total, hosted checkout URL, checkout session, MPP challenge, PDF preview). It also discloses the signature and payment-flow behaviors the schema cannot express.

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?

Dense but front-loaded: the primary action and return artifacts come first, then the approval/payment-routing details, then the alternative-tool pointer. Every sentence is load-bearing, though the MPP/x402 sentences are packed tightly enough to verge on run-on.

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?

Given 20 params, nested objects, and an output schema, the description covers the operationally risky parts — that drafting is free, what comes back, and which follow-up tool applies per payment path. The remaining gap is the unexplained address and mailing options, but nothing that blocks a correct call 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 description coverage is only 15% across 20 params, so the description must compensate, and it does partially: it explains the payment_protocol/hosted-vs-mpp choice and buyer_email requirement, and mentions typed/drawn signatures. But it is silent on the address_type enums, mail_class, certified, double_sided, color, sender/recipient address sourcing, and render options, leaving most parameters explained only by their names.

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 gives a precise verb+resource ('Prepare letter text for mailing' / 'Create a mail order draft from letter text') and explicitly distinguishes itself from siblings, stating it accepts text directly with 'no PDF upload or browser' (vs create_pdf_upload) and routing x402 users to create_machine_order. An agent can identify this tool without opening any schema.

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?

It names alternatives and the conditions that select them: use complete_checkout after buyer approval for Stripe tokens, set payment_protocol=mpp for MPP, use postalform.pay_order with the resulting order_id, and use postalform.create_machine_order for x402. When-to-use is spelled out explicitly rather than implied.

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

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

Annotations only give the generic readOnly=false/destructive=false/openWorld=true profile; the description goes well beyond by disclosing the MPP/x402 payment handshake, the idempotent retry expectation after a challenge, the checkout_url/status_url fallback, and the warning not to recreate the order. That is exactly the operational context an agent needs for a payment-mutating call.

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 core purpose is front-loaded in the first clause and every sentence carries routing or constraint information. It is dense and runs long as a single block, but there is little genuine padding.

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 29-parameter, nested, open-world payment tool with an output schema, the description covers the critical decision logic (payment path selection, bulk exclusivity, fallback flow). Remaining gaps are field-level details that the schema already documents, so it is nearly complete but not exhaustive.

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 only 38% across 29 parameters, so the description carries a real burden. It clarifies the bulk branch (exactly one of csv_content/recipients, content_mode semantics, template pairing) and the payment params, but leaves many top-level fields (mail_class, certified, postcard_size, sender/recipient address options, letter render/signature) to the schema, so it only partially compensates.

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 a specific verb pair (create/pay) and enumerates the exact resources: single PDF, letter, workflow-form order, or bulk letter campaign. It distinguishes itself from siblings by routing to draft tools + complete_checkout and to postalform.pay_order, so an agent can place it without opening a schema.

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?

It states explicit when/when-not branches: bulk MPP orders may use postalform.pay_order after fetching the challenge; SPT-capable single-recipient clients should use a draft tool then complete_checkout; walletless clients must present checkout_url and poll status_url. It even forbids an anti-pattern ('never recreate the order to change payment paths').

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

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

Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) establish the mutation and open-world profile, and the description adds genuinely useful behavioral context beyond them: 'Draft creation never pays' and the multi-step MPP flow ending in postalform.pay_order. Return contents are spelled out but an output schema already exists, so some of that is redundant.

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 purpose and return payload are front-loaded, and each subsequent sentence handles a distinct payment path. It is dense with protocol jargon across four sentences, but nothing is clearly wasted; a slightly tighter MPP sentence would help.

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 21-parameter mutation tool with an output schema, the description supplies the missing pieces: which payment paths exist, how they chain to sibling tools, and the explicit guarantee that no payment occurs at draft time. An agent has everything needed to call it correctly.

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 100%, so the schema already documents all 21 parameters, including payment_protocol, buyer_email, and the address fields. The description's mention of payment_protocol=mpp plus buyer_email adds a workflow-level coupling but largely restates what the schema fields already state, so the baseline 3 is appropriate.

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 states a specific verb and resource ('Prepare an existing PDF for mailing') and immediately enumerates what is returned (order ID, total, hosted checkout URL, checkout session). It also distinguishes itself from siblings by routing x402 use to postalform.create_machine_order and the letter/form variants are implicitly excluded by the PDF scope.

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?

It gives explicit when-to-use routing: hosted checkout by default, MPP when payment_protocol=mpp and buyer_email are set, and x402 via a different tool. It names the downstream alternatives (complete_checkout, postalform.pay_order) and the condition that selects each, leaving little to inference.

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

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

Annotations already declare a non-read-only, open-world, non-destructive operation. The description adds useful behavior beyond annotations: short-lived upload URL/token, multipart/form-data with a file field, and client-generated Content-Type boundary.

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?

Two compact sentences and one multipart instruction, with the usage condition front-loaded. Every sentence adds actionable information without repetition.

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?

Output schema exists, so return values need not be explained in the description. The definition covers when to use it and the multipart mechanics, though it leaves token expiry and authentication details unstated.

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 100%, so all four optional parameters are already documented in the schema. The description adds multipart context but no additional parameter-level meaning, so baseline 3 is appropriate.

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: creates a short-lived PDF upload URL and upload token. The upload-specific purpose clearly distinguishes it from sibling order, form, and address tools.

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 it: when the host cannot provide a PDF file param directly. It gives clear context but does not name exclusions or alternative sibling tools.

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

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 useful scope context ('supported single-mailpiece' workflow) and content shape, but says nothing about behavior for unsupported slugs or how to obtain valid ones.

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 zero filler; the trigger condition comes first and the payload description follows. Nothing could be trimmed without losing signal.

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?

With an output schema and full annotation coverage, the return shape and safety profile are handled. However, an agent still lacks guidance on where valid slugs come from (presumably list_forms) and on failure behavior for unsupported workflows, which is a real gap for a lookup tool.

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 100% with a single documented 'slug' parameter including an example ('8822'), so the baseline is 3. The description marginally reinforces that the slug must resolve to a supported single-mailpiece workflow but adds no syntax or validity detail beyond the schema.

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+resource (get form schema) and scopes it precisely to 'one supported single-mailpiece PostalForm workflow', enumerating what the schema contains (fields, groups, attachments, dependencies). This is clearly distinct from list_forms, though no sibling is named 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?

'Use this when you need a machine-usable schema...' is a when-to-use statement, but it is nearly circular — it restates the tool name. It names no alternative (e.g. list_forms for discovering valid slugs) and gives no when-not or prerequisite guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds genuinely non-obvious behavior: tracking events capped at the latest 50, missing carrier evidence returned as null, and the warning that processing state or a tracking number alone does not prove mailing or delivery. That is semantic context no annotation or schema could convey.

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 sentences, front-loaded with the return payload before the caveats and the negative scope statement. Every clause carries distinct information: field list, bulk-vs-individual routing, null semantics, and the non-action guarantee.

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?

Despite a rich output schema (which alone would absolve it of explaining return values), the description still pre-summarizes the payload shape and flags the bulk-order variation and null semantics. For a single-required-param read tool, nothing an agent needs to invoke it 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?

Only one parameter (order_id) and schema description coverage is 100%, with format/pattern fully specified in the schema. The description adds nothing about the identifier's syntax or sourcing, so the schema does all the work — the expected baseline of 3.

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?

Specific verb (read/get) plus a precise enumeration of what is returned: payment, processing, mailing/carrier status, latest 50 tracking events, return-receipt availability, plus bulk-order campaign fields. The closing clause 'does not pay, mail, or acquire receipts' cleanly separates it from siblings like pay_order and the create_* tools.

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?

It routes the agent for a real alternative case ('use the campaign dashboard for individual recipients') and implicitly tells the agent this is the status-check path rather than the pay/mail path. It stops short of an explicit when-to-use/when-not statement with named sibling tools, so it 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.

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is fully covered. The description's only added behavioral content is the inclusion/exclusion scope; it says nothing about pagination behavior or result ordering, which are relevant for a catalog listing.

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?

Two sentences, front-loaded with the use condition and no filler. The phrasing is slightly convoluted ('the published single-mailpiece PostalForm workflow catalog available to agents'), but nothing is gratuitous.

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?

With a full output schema present, return values need no explanation, and annotations cover the safety profile. The description supplies the scope boundaries an agent needs; only pagination/search semantics are left entirely to the schema, which is acceptable.

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 100% — q, limit (including max 200/default 50) and cursor are all documented in the schema. The description adds no syntax, matching behavior, or format detail beyond that, so the baseline of 3 applies.

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 identifies the resource precisely as the published single-mailpiece PostalForm workflow catalog and scopes it to what agents can use. It stops short of a clean verb+resource statement (it never literally says 'lists forms') and only distinguishes itself from siblings via scope language rather than by naming a competing tool.

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 opening 'Use this when you need...' gives a clear use condition, and the exclusion of coordinated statutory multi-recipient workflows tells the agent when NOT to use it. It does not, however, name an alternative tool (e.g. get_form_schema) that would serve the excluded case.

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

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

Annotations say readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the write/open-world nature is already declared. The description adds genuinely new behavioral context beyond that: without payment_authorization it only returns a challenge, with it, it can pay and send real mail, and no document or addresses are resubmitted. It notably reveals a real-world mailing side effect not captured by destructiveHint=false, though it does not spell out idempotency or permissions in depth.

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?

Six sentences, front-loaded with purpose then usage then behavior. Most sentences carry distinct value, but it is somewhat dense and a sentence like 'Review the preview or campaign_url, recipient count and total' mixes in output detail that could be trimmed.

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?

An output schema exists, so return values need not be enumerated, and the description still points to the returned payment status. Combined with clear inputs, prerequisites, retry behavior, and the challenge-vs-pay distinction, an agent has everything needed to invoke it correctly.

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 only 50%: payment_authorization is documented in the schema, but order_id has no schema description. The description compensates by explaining where order_id comes from (draft tools with payment_protocol=mpp, or create_machine_order) and that it should be reused verbatim on retries. That adds real meaning beyond the UUID format constraints.

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 (pay) and resource (existing MPP order across PDF, letter, form, or bulk campaign), plus the prerequisite (buyer approval) and the challenge-only mode. It also names the sibling create_machine_order, so an agent can distinguish it from the draft-creation tools without opening a schema.

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 to use the order_id returned by any draft tool with payment_protocol=mpp or by create_machine_order, and gives the exact procedure when switching from create_machine_order (omit the credential first to obtain this endpoint's challenge). Retry guidance is also given. Nothing about when/when-not is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and side-effect profile is fully covered. The description adds only the purpose framing, not extra behavioral detail such as latency, failure semantics, or what a 'unreachable' result looks like. Adequate but adds little beyond the 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?

A single front-loaded sentence with the usage condition first and zero filler. Every word earns its place for a tool this simple.

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 no-parameter health-check tool with full annotation coverage and an output schema that already describes the return value, the description contains everything the agent needs to select and call it correctly.

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?

The tool takes zero parameters, so there is nothing for the description to document beyond what the schema already shows. Baseline 4 applies for a no-parameter tool.

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 states a clear purpose: verifying that the PostalForm MCP server is reachable via a quick health check. The resource (server reachability) is specific and naturally distinct from all order/form siblings. It stops short of explicitly naming a sibling or contrasting itself, but no contrast is really needed here.

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?

It gives a clear triggering condition ('when you want a quick health check that the server is reachable'), which tells the agent the context for calling it. There is no when-not guidance or mention of alternatives, but for a ping tool no alternative is plausible.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely new behavior: that addresses are validated and that the result is a widget containing a create-draft action, which tells the agent what the output is and what the next step should be. It stops short of mentioning cost, expiry, or what happens on validation failure.

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 tight sentence pair, front-loaded with the 'use this to' cue and no filler. It is well sized, though the dense enumeration of three actions in one sentence slightly compresses detail that could have been spent on parameters.

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 17-parameter tool with nested address objects and zero schema descriptions, the description leaves the agent without guidance on how to supply addresses or which options exist. The output schema means return values need not be explained, but the input side is materially under-covered.

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% across 17 parameters with nested objects and three enums (sender/recipient_address_type, mail_class). The description says nothing about address types, manual vs. ID vs. text address forms, letter body limits, render options, or the request_id idempotency key, so it fails to compensate for the coverage gap beyond a vague nod to 'letter' and 'addresses'.

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 a specific verb and resource ('preview ... a mailed letter') and enumerates the three things it does: renders the letter, validates addresses, and returns a widget. It implies separation from the create-draft siblings via 'non-writing preview' and 'before creating checkout', but never names postalform.create_letter_order_draft explicitly, so sibling differentiation is only partial.

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?

'before creating checkout' gives a timing/ordering cue for when the tool fits, which is real but implicit guidance. There is no explicit when-not clause and no named alternative among the many create_* siblings, so the agent must infer the routing itself.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description correctly spends its words on behavior annotations cannot express: the two-phase Container → Address drill-down workflow, the US default for country_code, and which result types are order-eligible. It does not add rate-limit, auth, or result-count context, which keeps it short of a 5.

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, front-loaded with the core action and return shape, then the filtering detail, then the drill-down rule. No restatement of the name or filler.

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?

With an output schema present and full parameter documentation, the description only needs to cover what structured fields cannot: the multi-step container drill-down and result-type validity. Both are stated, leaving nothing an agent needs in order to call and chain this tool correctly.

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 a 3 is the baseline and the schema already documents all four parameters. The description goes further by explaining how container and query interact across successive calls and by reinforcing the country_code default, adding cross-call meaning the schema cannot convey; target is left to the schema.

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 ('search for a mailing address') plus the concrete return payload ('Loqate suggestions with IDs'). An agent can immediately distinguish this lookup tool from the sibling order-creation tools (create_order_draft, pay_order, etc.).

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?

Explicit when-to-use and follow-up routing: pass country_code to filter, and if a suggestion has type 'Container', call this tool again with container=<id> to drill down. It also states the terminal constraint that only type 'Address' is valid for order creation, telling the agent when a result is usable and when it is not.

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