Skip to main content
Glama
Sign In

Print and Mail Company

by com.printandmailcompany
OverviewDiscussionsAdmin

Check PDF for printing

check_pdf_margins
Read-onlyIdempotent

Use this when the user has a PDF they want printed and posted and it should be checked first: verifies the page size (A4 or US Letter) and the required free margin on every side, and lists the pages that need changes. We print on the paper size uploaded (printed_on): A4 on A4, US Letter on US Letter (for a recipient outside the US, Canada and US territories the user may choose A4 instead when sending); a PDF mixing A4 and US Letter pages is printed on A4, its Letter pages centred at 100 % or scaled down slightly when content comes close to the edge (us_letter_note, pages[].scale_percent). Decide by compliant: all_pages_a4 is false for a US Letter PDF, which is printable. Accepts a public https URL or base64. The file is not stored and nothing is sent. Works without sign-in. To fix a failing PDF, upload it with upload_document and use fix_document_margins.

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.
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. Changed2 schema fields changed
    • 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.4/5.0
Behavior5/5

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

Annotations already mark this read-only, idempotent and non-destructive, and the description still adds substantial context: the file is not stored, nothing is sent, and it works without sign-in. It also names the output fields (compliant, all_pages_a4, us_letter_note, pages[].scale_percent) that drive the decision, which is exactly what a no-output-schema tool needs.

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-loads the trigger and the verification behavior before the printing-rule detail, which is good ordering. However the middle section reads as dense run-on sentences about print paper selection that partly belong to the printing workflow rather than to a margin check.

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 carries the burden and does so: it explains the verification result, the all_pages_a4 pitfall (false for a printable US Letter PDF), and how to interpret scale_percent when pages are mixed. Auth, storage, and input-method concerns are all addressed.

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 both parameters (pdf_url, pdf_base64) are already fully documented including the alternative and the size caveat. The description only restates 'accepts a public https URL or base64', adding no new syntax or constraint beyond the schema, so the baseline of 3 applies.

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 concrete verb and resource: it verifies page size (A4/US Letter) and required free margins on every side, and lists pages needing changes. It also distinguishes itself from the sibling that remediates problems (fix_document_margins), so an agent can tell the two apart without reading either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Gives a clear trigger ('when the user has a PDF they want printed and posted and it should be checked first') and names the follow-up path via upload_document plus fix_document_margins. There is no explicit when-not-to-use case, so it stops just short of the top band.

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