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.6/5.0

Behavior4/5

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

Annotations already mark this as a non-readonly, non-idempotent, destructive operation. The description adds key behavior beyond annotations: 'Success means queued/submitted only—not delivered' and 'Side effects: queues outbound fax for delivery.' This clarifies the asynchronous nature of the action. No contradiction with annotations; the destructiveHint=true aligns with 'side effects' even though the operation creates rather than deletes.

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 dense but not bloated; every clause carries operational guidance. The main action is front-loaded, followed by usage context, exclusions, success semantics, and post-call status checking. Slight redundancy between 'Success means queued/submitted only' and the 'Side effects' line, but overall efficient 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 complexity (11 parameters, nested objects, output schema present) the description covers all critical context: required prerequisites (uploaded files), prohibited inputs (local paths, bytes), status verification flow, and user-facing communication guidance. Nothing an agent needs to invoke this correctly appears 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 description coverage is 100%, so baseline is 3. The description goes beyond the schema by clarifying that `files` come from the 'files POST JSON' or upload-file (typically /storage), and by reinforcing that `to` must be an array and local paths/bytes are forbidden. This adds practical usage meaning not captured in the parameter 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 verb and resource: 'Queue a new outbound fax using storage paths.' It clearly distinguishes this from related tools by defining the input type (storage paths, not bytes) and explicitly referencing sibling flows (request-file-from-user, upload-file, MCP Apps UI).

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 gives explicit when-to-use guidance: call after request-file-from-user or upload-file, never after the MCP Apps UI flow. It also provides exclusions ('Do not pass local filesystem paths or file bytes') and routes subsequent status checks to get-fax/get-outbox-fax with wait_seconds guidance. No inference is required.

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?