Skip to main content
Glama

Zovo Envelope Printer

Print addresses on envelopes

generate_envelope_pdf
Read-onlyIdempotent

Use this when the user wants to print addresses on envelopes ("print envelopes with addresses", "print envelopes from excel", "#10 envelope template", "a7 envelope template", "address wedding invitation envelopes", "print address on envelope"). First convert any pasted text or image of addresses into recipients objects (name, address1, address2, city, state, zip, country). Makes a PDF with one page per envelope at the real envelope size (#10 default, #9, #6 3/4, Monarch, A2, A6, A7, A9, 6x9, 9x12, 10x13, DL, C6, C5, C4 or custom), the return address in the top-left corner and the delivery address inside the USPS read area, in the destination country's line order. Each address gets an envelope; problems (missing ZIP, unknown state, wrapped lines) are listed. Also a CSV. Does not buy postage, print stamps or barcodes, verify addresses, or print label sheets.

Input Schema

NameRequiredDescriptionDefault
feedNoWith paper letter or a4: where the envelope sits in the tray, center (default), left or right.
fileNoOptional uploaded address list: CSV, TSV or Excel .xlsx with a header row (Name, Address, City, State, ZIP, Country), e.g. wedding guests.xlsx. Google Contacts, Outlook, Etsy and Shopify exports work.
sortNoOrder of the envelopes: none (list order, default), zip, name or country.
paperNoenvelope (default: each PDF page is the envelope size) or letter / a4 (the envelope is drawn turned on a full sheet, for printers that cannot take a custom size).
sheetNoExcel sheet to read, e.g. Guests. Default: the first sheet with data.
widthNoCustom envelope width with height, e.g. 9.5 or "229 mm". Numbers are inches unless above 30 (then mm).
heightNoCustom envelope height with width, e.g. 4.125 or "162 mm".
columnsNoColumn mapping when headings are unusual, field to heading, e.g. {"name":"Guest","address1":"Mailing Street","zip":"Postcode"}.
outlineNoDraw the envelope edge on every page (for checking on plain paper). Default false.
addressesNoSame as recipients (either name works).
bold_nameNoPrint the recipient's name in bold, e.g. true. Default false.
font_sizeNoAddress text size in points, 8 to 24, e.g. 12. Default 12 (11 on narrow envelopes). Long lines shrink to fit and wrap; nothing is cut off.
test_pageNoAdd a first page with the envelope outline and sample text, to print on plain paper and hold against an envelope. Default true.
uppercaseNoUSPS style: all capitals without periods or commas, e.g. true. Default false.
recipientsNoThe addresses, one envelope each. Convert what the user pasted or showed in an image into objects first, e.g. [{"name":"Jane Smith","address1":"123 Main St","address2":"Apt 4B","city":"Springfield","state":"IL","zip":"62704"}, {"name":"Hans Müller","address1":"Hauptstr. 5","zip":"10115","city":"Berlin","country":"Germany"}]. Text also works: one string per address with lines separated by \n, or the whole pasted list as one string with a blank line between addresses, or pasted CSV with a header row.
home_countryNoCountry you mail from; the country line is printed only for other countries, e.g. "UK". Default: the return address's country, else United States.
envelope_sizeNoEnvelope size: 10, 9, 6-3/4, monarch, a2, a6, a7, a9, 6x9, 9x12, 10x13, dl, c6, c5, c4 or a custom size like "5.5 x 8.5 in" or "114 x 229 mm". Synonyms work: "business" = 10, "5x7" or "invitation" = a7, "rsvp" = a2. Default 10.
return_addressNoSender address for the top-left corner, as text with \n or commas between lines, a list of lines, or an object, e.g. "The Garcia Family\n42 Oak Lane\nPortland, OR 97205". Leave out for no return address.
include_home_countryNoAlso print the country line for addresses in your own country when a country is given. Default false.

Output Schema

NameRequiredDescriptionDefault
feedYes
notesYes
paperYes
issuesYes
assumedYes
previewYes
envelopeYes
countriesYes
downloadsYes
envelopesYes
file_nameYes
pdf_pagesYes
test_pageYes
usps_noteYes
duplicatesYes
font_size_ptYes
home_countryYes
issues_countYes
preview_countNo
return_addressYes
printed_as_givenYes
smallest_font_ptYes
print_instructionsYes
links_expire_minutesYes
envelopes_with_issuesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses layout behavior (return address top-left, delivery address in the USPS read area, destination-country line order), per-address page generation, that problems like missing ZIP or wrapped lines are reported back, and that a CSV is also produced. The explicit negative capabilities further bound the tool's behavior.

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?

It is a single dense paragraph, but the trigger condition and exclusions are front- and back-loaded correctly and every clause carries informational weight. The long parenthetical list of utterance examples is somewhat bulky.

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?

For a 19-parameter tool with nested objects, an output schema, and existing annotations, the description covers purpose, input preparation, sizing defaults, layout, error reporting, and scope exclusions. Nothing required 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.

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, but the description adds real meaning: the default #10 size and the full size vocabulary including custom sizes, and the instruction to first convert pasted text or images into recipients objects before calling. It does not walk through the many formatting flags, but the schema already documents those thoroughly.

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

Purpose4/5

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

The description opens with a specific verb and resource ('print addresses on envelopes') plus concrete trigger phrasings, and states precisely what is produced ('Makes a PDF with one page per envelope at the real envelope size'). It never references the sibling find_envelope_size, so the boundary with that tool is left implicit rather than stated.

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?

It gives an explicit when-to-use trigger ('Use this when the user wants to print addresses on envelopes') with six example utterances, plus a clear when-not list: no postage purchase, no stamps or barcodes, no address verification, no label sheets. An agent can decide to call or skip without inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources