Skip to main content
Glama
klodr

faxdrop-mcp

by klodr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

faxdrop_send_fax

Destructive

Send a document as a real fax through FaxDrop to a fax number, supporting PDF, DOCX, JPEG, or PNG files up to 10MB. Use it for medical, legal, or government submissions that require fax delivery.

Instructions

Send a real fax via FaxDrop.

USE WHEN: user needs to fax a document (PDF, DOCX, JPEG, PNG ≤10MB) to a fax number — medical records, legal forms, government submissions, recipients who only accept fax.

DO NOT USE: for digital delivery (email, sftp), for files outside the outbox, for non-fax numbers — the 3-layer phone gate (TYPE → COUNTRY → per-number policy) rejects mobile/landline/premium.

SIDE EFFECTS: charges FaxDrop balance (or consumes free credits + adds branded cover on free tier), creates an audit log entry, allocates a fax ID server-side. ALWAYS confirm recipient + file + cover with the user before calling.

FILE LOCATION: document must live inside the outbox (default ~/FaxOutbox/, override via FAXDROP_MCP_WORK_DIR). Files outside are rejected — ask the user to copy in first.

RETURNS: { faxId, status: "queued", ... } — poll with faxdrop_get_fax_status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
subjectNoCover page subject / RE: line (max 200 chars).
filePathYesAbsolute path to the document to fax (PDF, DOCX, JPEG, or PNG, ≤10MB).
coverNoteNoMessage printed on the cover page (max 500 chars). Only used when includeCover is true.
sendEmailNoWhether FaxDrop should email the sender a per-fax delivery confirmation. Defaults to **false** (suppress) — the MCP is built for batch / agent workflows where one email per fax floods the inbox, and the same information is already available via `faxdrop_get_fax_status`. Set to true to opt back into the confirmation email. Failed-fax emails, operator alerts, refunds and status pages are unaffected. The send response echoes `deliveryEmail: enabled | suppressed`.
senderNameYesSender display name shown on the cover page.
senderEmailYesSender email for delivery confirmation.
senderPhoneNoSender callback number shown on the cover page (E.164 format).
includeCoverNoInclude a FaxDrop cover page. Free accounts always include a branded cover regardless; paid accounts default to false. The cover-page fields below (coverNote, recipientName, subject, senderCompany, senderPhone) are only printed when includeCover is true.
recipientNameNoRecipient display name on the cover page, e.g. "Dr. Jane Smith" (max 50 chars).
senderCompanyNoSender company shown on the cover page (max 100 chars).
recipientNumberYesRecipient fax number, international (E.164) format with leading + and country code, e.g. +12125551234

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.10.1
    • changedInput schema / properties / senderEmail / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
  2. Changed1 schema field changedv0.10.0
    • addedInput schema / properties / sendEmail
      Added value: +{
+  "default": false,
+  "description": "Whether FaxDrop should email the sender a per-fax delivery confirmation. Defaults to **false** (suppress) — the MCP is built for batch / agent workflows where one email per fax floods the inbox, and the same information is already available via `faxdrop_get_fax_status`. Set to true to opt back into the confirmation email. Failed-fax emails, operator alerts, refunds and status pages are unaffected. The send response echoes `deliveryEmail: enabled | suppressed`.",
+  "type": "boolean"
+}
  3. Addedv0.8.7
  4. Removedv0.8.5
  5. Addedv0.8.4
  6. Removedv0.8.2
  7. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and openWorldHint=true, and the description adds substantial value beyond them: balance charges, free-tier branded-cover behavior, audit-log creation, server-side fax ID allocation, the outbox file-location constraint, and an explicit 'ALWAYS confirm recipient + file + cover' instruction. This is exactly the mutation/irreversibility context an agent 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?

Header-structured and front-loaded with purpose, then use/avoid, side effects, file rules, and return shape. Dense but every block carries operational weight; only the free-tier cover detail borders on surplus.

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?

No output schema exists, yet the description supplies the return shape ({ faxId, status: 'queued', ... }), the polling next step, and the preconditions (outbox location, balance charge). Complete for an 11-param mutation tool.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: the file must reside inside the outbox (rejected otherwise, with the FAXDROP_MCP_WORK_DIR override), and the cover-page fields are gated on includeCover — cross-parameter behavior not captured in the flat 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?

States a specific verb+resource ('Send a real fax via FaxDrop') and immediately differentiates from the sibling by pointing to faxdrop_get_fax_status for polling. An agent can tell exactly what this does versus the read-status tool.

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?

Explicit USE WHEN section lists document types and use cases, DO NOT USE section names the excluded channels (email, sftp) and the 3-layer phone gate that rejects mobile/landline/premium. Alternatives and conditions are all spelled out.

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

Deploy Server

Other Tools