Cloudlabels

Send PDF email

send_pdf_email

Destructive

Requires print. Email a PDF that this MCP session already created. job_id comes from print_labels, print_shipping_mark, or a completed start_print_job. Without to, the message goes to the Cloudlabels user on this API key. Pass to only when the user asked for another address. Optional cc and bcc are a string or an array of up to 5 addresses each. Optional reply_to sets only the Reply-To header. From stays the Cloudlabels Resend domain. Recipients across to, cc, and bcc are limited to 10 after duplicates are removed. The body is a short note and the download link, not an order table. Line breaks in note stay in the email. A block of lines that all start with "1. " or "- " becomes a list. The PDF is attached. Sends immediately when every recipient is you or another member of this organization. An address on to, cc, or bcc is external when it is not the API key user and not another user email in this organization. Comparison folds ASCII A-Z only. reply_to is not a recipient. External recipients require a confirm step: the first call does not send. It returns confirmation_required, confirm_token, and summary with recipients, reply_to, subject, the note, and pdf_name. Call again with the same arguments plus confirm_token. The token is bound to this key, this organization, and the exact recipients, subject, note, and PDF. It expires in 5 minutes and works once. A confirm boolean is ignored. From stays the Cloudlabels Resend domain.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "job_id": "<job_id>"
    },
    "name": "send_pdf_email"
  }
}

Input Schema

Name	Required	Description	Default
`cc`	No
`to`	No
`bcc`	No
`note`	No
`job_id`	Yes
`subject`	No
`reply_to`	No
`confirm_token`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say destructive/openWorld/non-idempotent; the description adds the substantive behavior: default recipient resolution, the two-step external-recipient confirm with token binding (key, org, recipients, subject, note, PDF), 5-minute single-use expiry, that `confirm` boolean is ignored, immediate send for org-internal recipients, and that the PDF is attached with a link+note body. This is far beyond what annotations convey.

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?

Information-dense and mostly front-loaded, but it is a single ~250-word paragraph with notable redundancy — "From stays the Cloudlabels Resend domain" appears verbatim at both the start and end — and the two-word opener "Requires print." is cryptic before context arrives. Grouping the recipient rules, confirm flow, and body formatting would make it scannable.

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 an 8-parameter, open-world, destructive, non-idempotent tool with no output schema and 0% schema coverage, the description covers the send path, the confirmation path including the returned fields (confirmation_required, confirm_token, summary), and the failure/retry semantics (token expiry, single use, argument binding). 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.

Parameters5/5

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

Schema coverage is 0%, so the description carries the full burden and mostly does: job_id provenance, `to` default vs. override rule, cc/bcc as string-or-array up to 5 each with a 10-recipient post-dedup cap, reply_to affecting only the Reply-To header and not counting as a recipient, note line-break/list-collapsing rules, and confirm_token's purpose and lifetime. Only `subject` and `note` max-lengths are left to 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?

Opens with a specific verb+resource ("Email a PDF") and immediately scopes it to a PDF this MCP session already created, which cleanly separates it from list_pdfs/delete_pdf and from print_labels/start_print_job. An agent can tell exactly what this does 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?

States where job_id comes from (print_labels, print_shipping_mark, completed start_print_job) and names the alternative path. It also gives an explicit conditional for the `to` override ("Pass to only when the user asked for another address") and routes the agent into the confirm-token flow for external recipients.

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

All Cloudlabels tools Inspect

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

Need Help?