Emboss

Send a PDF by fax

send_fax

Send a PDF to a fax number and track delivery, priced per transmitted page. Give a destination in E.164 form (for example +15025551212; US, Canadian and Mexican numbers only) and the PDF: an artifact_id from any earlier result, a job_id from fill_form_from_context or commit_proposal once get_job reports ready, a form_id for the fillable form, or one PDF by pdf_url or pdf_base64, or a sources list of artifact ids (each with an optional pages range such as 1-3,7) faxed together as one packet. Returns a job id at once; poll get_fax for delivery. Billed per page at delivery; a failed fax is not charged. Needs a payment method on the account; get_usage reports fax_ready. Pass dry_run=true to rehearse this call without doing it: nothing is stored, charged or sent, and no AI is used. The answer says whether the real call would succeed or be refused, what it would cost, and what a rehearsal cannot check.

Input Schema

Name	Required	Description	Default
`to`	Yes
`job_id`	No
`dry_run`	No
`form_id`	No
`pdf_url`	No
`sources`	No
`pdf_base64`	No
`artifact_id`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "job_id": "77777777-8888-9999-aaaa-bbbbbbbbbbbb",
-    "to": "+15025550123"
-  }
-]New value: +[
+  {
+    "job_id": "77777777-8888-9999-aaaa-bbbbbbbbbbbb",
+    "to": "+15025550123"
+  },
+  {
+    "dry_run": true,
+    "job_id": "77777777-8888-9999-aaaa-bbbbbbbbbbbb",
+    "to": "+15025550123"
+  }
+]

addedInput schema / properties / dry_run

Added value: +{
+  "default": false,
+  "title": "Dry Run",
+  "type": "boolean"
+}

Changed1 schema field changedOct 10, 2026

addedInput schema / examples

Added value: +[
+  {
+    "job_id": "77777777-8888-9999-aaaa-bbbbbbbbbbbb",
+    "to": "+15025550123"
+  }
+]

First observedSep 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Although annotations cover safety traits (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), the description adds crucial context beyond them: billing is per transmitted page, failed faxes are not charged, a payment method is required, dry_run rehearses without storing/charging/sending, and the response indicates success, cost, and rehearsal limits. This is rich behavioral detail that helps an agent invoke the tool responsibly.

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?

The description is front-loaded with purpose and pricing, then covers parameters, returns, billing, and dry_run. It is dense and efficient, though some sentences are long and run together, which slightly reduces readability. Content is appropriate for the tool's complexity.

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 that an output schema exists, the description need not explain return values in full. It still mentions the immediate job id and polling with get_fax. It covers prerequisites, billing, dry_run behavior, and all parameter sources, making it complete for an agent to call the tool correctly.

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?

With 0% schema description coverage, the description fully compensates by explaining every parameter: `to` must be E.164 and limited to US/Canada/Mexico; PDF can come from artifact_id, job_id, form_id, pdf_url, pdf_base64, or a sources list with optional page ranges; and dry_run has explicit semantics. It also clarifies source mutual exclusivity implicitly via 'or one PDF by... or a sources list'.

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?

The description states a specific verb and resource: 'Send a PDF to a fax number and track delivery, priced per transmitted page.' It distinguishes this tool from siblings by naming get_fax for polling, fill_form_from_context/commit_proposal/get_job as source providers, and get_usage for fax readiness. An agent can identify the tool's role without ambiguity.

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?

The description gives clear context for use: send a PDF, poll get_fax for delivery, ensure payment method exists, and check get_usage for fax_ready. It details valid PDF sources and when to use dry_run. It does not explicitly state when not to use this tool or name a direct alternative for sending, but the usage conditions are otherwise clear.

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

All Emboss 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.