Prepare a USPS Certified Mail letter (optional Electronic Return Receipt) to any US address from ChatGPT, Claude or Grok. The assistant hands over the finished letter text or PDF; a person reviews the exact pages, pays and authorizes. The tool never mails or charges on its own. Docs: https://github.com/Piloxa/piloxa
Score is being calculated.
Prepares a Certified Mail (with optional Electronic Return Receipt) sending for a human to review, edit if they wish, pay for and authorize. Hand over the document ONE of three ways: (1) letter_text — the COMPLETE final letter (salutation through closing); the server lays it out as a locked PDF and the person can still edit the wording on the review page; (2) document_base64 — the bytes of a FINISHED PDF the person already has (only when you can actually read the file; up to 4 MB), preserved byte for byte and never rewritten; (3) person_has_pdf: true — the person will attach the PDF themselves on the review page, everything else prefilled. Pass sender and recipient address fields whenever they are known; any missing address details are collected from the person on the review page before mailing can be authorized. This tool NEVER mails anything and never charges anyone. It returns a review link showing the available document, recipient, service and estimated price; the letter is only produced after the person completes the review and pays on that page.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| state | No | Two-letter U.S. state code. | |
| service | No | CERTIFIED_ERR adds the Electronic Return Receipt (proof of who signed). | |
| subject | No | The "Re:" line of the letter, in a few words. | |
| page_count | No | Only with person_has_pdf: number of pages in the PDF the person will attach, used for the price estimate. | |
| letter_date | No | Date to print on the letter, e.g. "September 5, 2026". Defaults to today. | |
| letter_text | No | The complete, final letter body exactly as it should print: salutation, paragraphs separated by blank lines, and closing. Do not include the addresses or date; they are laid out from the other fields. Up to 60,000 characters. | |
| postal_code | No | Five-digit ZIP code. | |
| sender_city | No | ||
| sender_name | No | Name of the person sending the letter (printed as the return address and used for the envelope). | |
| sender_state | No | Two-letter U.S. state code. | |
| address_line1 | No | Street address of the recipient. | |
| address_line2 | No | Suite, unit or floor. | |
| person_has_pdf | No | Only when the person already has a finished PDF that you cannot read and they will attach it on the review page themselves. Set true to prepare without letter_text or document_base64. | |
| recipient_name | Yes | Name of the person or company receiving the letter. | |
| sender_company | No | Sender company or entity, if any. | |
| signature_name | No | Name printed under the closing. | |
| document_base64 | No | The finished PDF, base64-encoded (standard or URL-safe alphabet), up to 4 MB decoded. Use ONLY when you have read the actual file bytes; a filename or an attachment reference is not a document. Mutually exclusive with letter_text. The file is kept exactly as sent. | |
| document_sha256 | No | Optional with document_base64: the SHA-256 (hex) of the PDF bytes. If given and it does not match what arrived, the call is refused rather than preparing the wrong file. | |
| document_filename | No | With document_base64: the original file name, e.g. "Demand letter.pdf". | |
| recipient_company | No | Company name, if the letter goes to an organization. | |
| sender_postal_code | No | Five-digit ZIP code. | |
| document_description | No | What the document is, in a few words. | |
| sender_address_line1 | No | Sender street address. | |
| sender_address_line2 | No |
| Name | Required | Description |
|---|---|---|
| mailed | Yes | Always false here: this tool never mails. |
| charged | Yes | Always false here: this tool never charges. |
| service | No | |
| page_count | No | |
| approval_url | Yes | Link the person opens to review, pay and authorize. |
| document_sha256 | No | SHA-256 of the rendered PDF, when document_rendered is true. |
| upload_required | No | True when the person still has to attach the PDF on the review page. |
| document_received | No | True when document_base64 arrived intact and is the PDF the person will review; false otherwise. |
| document_rendered | No | True when letter_text was rendered into the PDF the person will review; false otherwise. |
| estimated_total_cents | No | |
| requires_human_approval | Yes | |
| estimated_service_fee_cents | No | |
| estimated_provider_cost_cents | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses critical behaviors: 'This tool NEVER mails anything and never charges anyone' and that it returns a review link; the letter is only produced after review/payment. It also clarifies that document_base64 files are preserved byte-for-byte and that missing address details are gathered on the review page. This adds substantial context not present in 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 a single dense paragraph that is front-loaded with the core purpose and then systematically details the three modes. Every sentence contributes actional information—no filler. It is longer than a minimal description but appropriately detailed for a tool with 25 parameters; the structure is logical and easy to follow.
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 the high complexity (25 parameters, 88% schema coverage, output schema present), the description covers all critical aspects: the three ways to supply content, when each is appropriate, the no-mail/no-charge guarantee, the review link flow, and the collection of missing address details. There are no obvious gaps that would prevent an agent from using the 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 88%, so the schema already documents most parameters well. The description adds meaningful semantics by explaining the three modes (letter_text, document_base64, person_has_pdf) and their mutual exclusivity, plus guidance to pass addresses when known. It does not repeat every parameter but clarifies the key interactions and constraints, which goes 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?
The description opens with a specific action and resource: 'Prepares a Certified Mail ... sending for a human to review, edit, pay for and authorize.' It then clearly enumerates the three distinct ways to provide the document, making the tool's function unambiguous. Even without siblings, it fully separates the tool from generic PDF or mail-related 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?
The description gives explicit when-to-use guidance for each document-delivery mode ('letter_text' for a complete letter, 'document_base64' for a finished PDF you can read, 'person_has_pdf' when the user will attach it). It also instructs to pass address fields whenever known and notes that missing details are collected later. This is actionable and complete given no sibling tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
prepare_certified_letter
