Fax.Plus

Send fax from uploaded files

send-fax-uploaded

Destructive

Queue a new outbound fax using storage paths. Call this after an agentic request-file-from-user curl (files = path from the files POST JSON) or after upload-file (automation). Do not call this after the MCP Apps UI flow — the widget already sent. Pass paths here with to/from and optional send_time. Do not pass local filesystem paths or file bytes. to must be an array. The same paths may be reused for multiple sends. Success means queued/submitted only—not delivered. Tell the user the fax was submitted. If you check status, call get-fax or get-outbox-fax with the returned id and optional wait_seconds=30 on that first check (omit wait_seconds later). Do not narrate tool names or HTTP details to the user.

Side effects: queues outbound fax for delivery.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	Yes	Destination fax numbers as a JSON array of E.164 strings, e.g. ["+15551234567"]. Never a bare string.
`from`	Yes	Sender fax number in E.164 form, e.g. +15559876543.
`files`	Yes	Uploaded file paths from the files POST JSON (agentic request-file-from-user) or from upload-file (typically starting with /storage).
`comment`	No	Optional comment to set for the fax job.
`options`	No	Optional send options.
`user_id`	No	Optional Fax.Plus user ID. Omit for self. Must be a UUID (dashed or 32-hex) or 24-char ObjectId (not a phone number).
`send_time`	No	Optional scheduled send time, format YYYY-MM-DD HH:mm:ss +HHMM.
`cover_page`	No	Optional fax cover page payload.
`resolution`	No	Optional resolution: fine or superfine.
`return_ids`	No	Ignored; fax IDs are always returned on success.
`pipeline_id`	Yes	Returned by pipeline_start. Pass it back unchanged.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`queued`	Yes
`fax_ids`	No
`message`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, the description reveals the key behavioral nuance that success means only queued/submitted, not delivered, and explicitly states the side effect: 'queues outbound fax for delivery.' It also clarifies that paths may be reused, which reduces unnecessary caller caution. No contradiction with annotations exists.

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 long but every section earns its place: preconditions, exclusions, parameter cautions, success semantics, follow-up status guidance, and user-facing communication rules. The core action is front-loaded, though the operational messaging guidance could arguably be split out without losing invocation value.

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 11-parameter tool with nested objects and an output schema, the description is comprehensive: it covers prerequisites, invalid inputs, scheduling, result interpretation, follow-up status checks, and user messaging. The existence of an output schema relieves it from describing return values, and nothing essential is missing.

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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it ties the files parameter to upstream responses ('files = path from the files POST JSON'), forbids local filesystem paths and file bytes, emphasizes that to must be an array, and indicates send_time is optional. These are useful semantic constraints not fully captured in individual property descriptions.

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 opens with a specific action and resource: 'Queue a new outbound fax using storage paths.' It clearly differentiates this from upstream file-upload tools and from the MCP Apps UI flow, so an agent knows exactly what this tool does and how it fits with siblings like get-fax and upload-file.

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 explicitly says when to call this tool ('after an agentic request-file-from-user curl... or after upload-file') and when not to ('Do not call this after the MCP Apps UI flow'). It also tells the agent which tool to use next for status checks and how to pass wait_seconds on the first check.

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

All Fax.Plus 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?