Skip to main content
Glama

Send a fax

send_fax

Submit an uploaded PDF for faxing.

Step 1 (before this tool): upload the PDF over plain HTTP multipart, using any HTTP client you have — shell, JavaScript fetch with FormData, Python, etc.: curl -F "file=@document.pdf" https://www.sendthisfax.com/api/upload fetch("https://www.sendthisfax.com/api/upload", {method: "POST", body: formDataWithFile}) The response contains fax_public_id and page_count. PDFs must be unencrypted, at most 50 MB and 1000 pages.

Step 2: call this tool with the fax_public_id and the recipient fax number.

Two modes:

  • With an API key (Authorization: Bearer stf_live_... on this MCP connection): the fax price is debited from the prepaid credit balance and sending starts immediately — no checkout, no browser. sender_email and billing_country are optional (they default to the key's records). Buy credits at https://www.sendthisfax.com/en/credits.

  • Without an API key: sender_email and billing_country are REQUIRED and the tool returns a checkout_url the USER must pay in a browser; the fax is sent automatically once paid.

In both modes, poll get_fax_status until status reaches "delivered" or "failed" (failures after payment are auto-refunded).

For integration testing, +19898989898 is the designated test recipient number.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
localeNoLanguage for emails and the checkout page (default: en)
sender_emailNoPayer email for the receipt and delivery notification. Required without an API key; defaults to the key's email otherwise.
fax_public_idYesThe fax public id (fax_...) from the upload step
billing_countryNoISO 3166-1 alpha-2 country of the payer, determines VAT. Required without an API key; fixed by the key's first purchase otherwise.
recipient_numberYesRecipient fax number in E.164 format, e.g. +49301234567

TDQS

A5/5.0
Behavior5/5

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

Annotations already indicate mutability, but the description adds crucial behavioral details: immediate sending with API key versus checkout URL without, auto-refund on failure, and the need to poll for status. No contradictions with annotations.

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

Conciseness5/5

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

The description is well-structured with numbered steps and bullet points. It is front-loaded with the core action, and every sentence provides essential information without unnecessary verbosity. The length is appropriate for the 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 the tool's multi-step process, two modes, and payment requirements, the description covers all necessary context: upload prerequisites, parameter dependencies, checkout flow, and post-send polling. It even mentions a refund policy and test number.

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?

Input schema has 100% description coverage, so parameters are fully documented. The description adds extra context, such as conditions when sender_email and billing_country are required, default values, and the test recipient number. Examples are also provided.

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 clearly states the tool submits an uploaded PDF for faxing, distinguishing it from sibling tools like check_balance, get_fax_status, and get_price. The step-by-step process and use of specific verbs make the purpose unambiguous.

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?

The description provides explicit when-to-use instructions: after uploading a PDF. It details two modes (with/without API key), when parameters are required, and how to poll for status. It also includes a test recipient number and references alternative tools for polling.

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.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: checking balance, getting fax status, pricing, and sending. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: check_balance, get_fax_status, get_price, send_fax.

Tool Count5/5

Four tools is appropriate for a focused fax service, covering the essential operations without unnecessary clutter.

Completeness4/5

Core workflow (price, send, status, balance) is covered. Missing cancellation or listing tools, but these are not essential for the primary use case.

Resources