Skip to main content
Glama
mailbox-mcp

mailbox-mcp

create_batch_mail

Creates a batch mail draft from a template link and recipient list, skips malformed or duplicate rows, and returns exact pricing plus a proof before credits are charged.

Instructions

Create a batch draft from a template link and a recipient list; nothing is charged. template_url is a public https:// link to a PDF at the mail type's size, or to a PNG/JPG postcard graphic that is set on a page at that size (design 4×6 in at 300 dpi = 1200×1800 px). Recipients go inline (an array of {name, line1, line2, city, state, zip}; company accepted) or as recipients_url, a CSV link. Malformed rows and duplicates are skipped and listed, never charged. A one-page postcard gets an address side printed with the return address. The result carries the exact price, the first recipients and any image warnings; then call get_batch_mail_proof and give the person its proof_url, which opens in any browser for an hour, to see the template and a sample address label before confirm_batch_mail charges credits. Requires mailbox_md_version from get_mailbox_md. A key that requires approval saves the draft for the account owner to pay in the dashboard. Postcards from 1 recipient (a $2.00 small-batch fee under 10); letters, flyers and pamphlets from 10; up to 10,000.

Input Schema

NameRequiredDescriptionDefault
colorNoColor printing for letters, flyers and pamphlets, charged per color page (postcards are always full color). Default false.
duplexNoPrint both sides of each sheet. Default false.
job_nameYesA name the owner will recognise in the dashboard and in emails, e.g. "Spring open house postcards".
mail_typeYespostcard_4x6, postcard_6x9, letter (1–3 pages, 6 with duplex), flyer (1 page), pamphlet_light (4–8 pages), pamphlet_heavy (9–16 pages).
column_mapNoFor recipients_url only, when the CSV headers are not recognised: field (name, line1, line2, city, state, zip) → the header text in the file.
recipientsNoInline recipients, up to 10,000 (postcards from 1, other types from 10). Skipped rows are reported by position (1 = first). Send this or recipients_url, not both.
return_zipNoReturn ZIP code.
return_cityNoReturn city.
return_nameNoReturn name. Defaults to the account's saved return address.
return_line1NoReturn street address. Defaults to the account's saved return address.
return_line2NoReturn suite or unit.
return_stateNoReturn state, 2 letters.
template_urlYesPublic https:// link to the template (PDF, PNG or JPG, ≤10 MB). Signed cloud-storage links, CDN and GitHub raw URLs work; links that need a login, private hosts and IP addresses are refused.
mailing_classNofirst_class (USPS First-Class Mail, 1–5 days, forwarded and returned; the default) or marketing_mail (USPS Marketing Mail, 3–10 days, 200+ recipients; not open until the facility's USPS permit is active). The class is USPS postage, not a description of the content: bills, statements and personal correspondence must go first_class.
recipients_urlNoPublic https:// link to a recipients CSV (columns name, address, address2, city, state, zip; ≤5 MB). Send this or recipients, not both.
return_companyNoReturn company line.
mailbox_md_versionYesYour current MAILBOX.md version from get_mailbox_md. Required for agent keys.

Output Schema

NameRequiredDescriptionDefault
resultYesThe draft: batch (status draft, pricing, recipients summary, links.proof), recipients_preview, template (how it was taken), warnings and next_step.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.4

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare non-read-only, non-idempotent and open-world, but the description adds substantive behavior: no charge at draft time, malformed rows and duplicates are skipped and listed rather than failing, an approval-requiring key saves the draft for the owner to pay, and the proof link expires after an hour. It even discloses pricing thresholds (a $2.00 small-batch fee under 10 postcards).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and the no-charge fact, then layers in constraints, but it is a single dense block of semicolon-joined clauses. Most content earns its place, though the postcard-design pixel arithmetic is a slight tangent that could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 17 parameters, nested recipient objects, an output schema and existing annotations, the description still covers the missing pieces: prerequisites, the downstream proof/confirm flow, recipient-count minimums, and what the result contains. Nothing an agent needs to invoke this correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining template_url constraints (public https, size-matched PDF or PNG/JPG graphic, design dimensions at 300 dpi) and that 'company' is accepted as a recipient key. It stops short of documenting the return_* defaults or duplex/color semantics, which live only in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a batch draft from a template link and a recipient list') and immediately scopes it against the charging step ('nothing is charged'), so an agent can distinguish it from confirm_batch_mail and estimate_batch_mail 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly chains the workflow: create the draft here, then call get_batch_mail_proof and give the person its proof_url, then confirm_batch_mail charges credits. It also states the inline-vs-recipients_url exclusion ('Send this or recipients_url, not both'), the prerequisite (mailbox_md_version from get_mailbox_md), and the approval-key path.

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