Skip to main content
Glama
Sign In

Print and Mail Company

by com.printandmailcompany
OverviewDiscussionsAdmin

Upload a PDF

upload_document

Use this when the user already has a PDF (public https URL or base64) that should be printed and posted. Stores the file in the user's account, runs the print check (A4 or US Letter, free margins; printed_on says the paper: US Letter PDFs are printed on US Letter, a PDF mixing A4 and US Letter pages on A4, see us_letter_note; decide by compliant, as all_pages_a4 is false for a US Letter PDF) and returns document_id for create_letter. If the check fails, call fix_document_margins or ask the user for a corrected file. For a file on the user's own device, use create_upload_link instead. Sends nothing. Needs the user's account.

Input Schema

NameRequiredDescriptionDefault
pdf_urlNoPublic https URL of the PDF (A4 or US Letter pages), e.g. https://example.com/letter.pdf. Pass pdf_url or pdf_base64.
file_nameNoName to store the file under, e.g. cancellation.pdf. Default: the name from the URL, or "document.pdf".
pdf_base64NoThe PDF file as base64 (a data:application/pdf;base64, prefix is fine), for files up to about 3 MB. Pass pdf_url or pdf_base64. Larger files: pass pdf_url, or use create_upload_link.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / file_name / description
      Added value: +"Name to store the file under, e.g. cancellation.pdf. Default: the name from the URL, or \"document.pdf\"."
    • changedInput schema / properties / pdf_base64 / description
      Previous value: -"The PDF as base64, for files up to about 3 MB. Larger files: pass pdf_url, or use create_upload_link."New value: +"The PDF file as base64 (a data:application/pdf;base64, prefix is fine), for files up to about 3 MB. Pass pdf_url or pdf_base64. Larger files: pass pdf_url, or use create_upload_link."
    • addedInput schema / properties / pdf_url / description
      Added value: +"Public https URL of the PDF (A4 or US Letter pages), e.g. https://example.com/letter.pdf. Pass pdf_url or pdf_base64."
  2. Changed1 schema field changed
    • addedInput schema / properties / pdf_base64 / description
      Added value: +"The PDF as base64, for files up to about 3 MB. Larger files: pass pdf_url, or use create_upload_link."
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare the mutation profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false), but the description adds material context beyond them: it stores the file in the account, requires the user's account, 'Sends nothing' (clarifying no letter is dispatched), and returns document_id for the downstream create_letter step. The A4/US Letter print-check explanation is tangled but genuinely discloses what the tool computes.

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

Conciseness3/5

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

The when-to-use and alternatives are front-loaded well, but the parenthetical about printed_on, compliant, all_pages_a4, and us_letter_note is dense, circular, and hard to parse. That clause costs more attention than it earns.

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?

With no output schema, the description still explains the return value (document_id for create_letter), the auth requirement, the no-send guarantee, the alternative tool, and the remediation path. Nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so pdf_url, file_name, and pdf_base64 are already fully documented in the schema. The description adds no syntax or format detail beyond that, so the baseline 3 is appropriate.

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 ('upload_document' stores a PDF in the user's account, runs a print check, and returns document_id for create_letter) and distinguishes itself from the sibling create_upload_link for on-device files. An agent can identify the tool's role without opening the 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 names the trigger ('when the user already has a PDF... that should be printed and posted'), the alternative for a different input source ('For a file on the user's own device, use create_upload_link instead'), and the failure path ('call fix_document_margins or ask the user for a corrected file'). This is the strongest kind of routing guidance.

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

All Print and Mail Company toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources