XipFax

Add a file to a fax

add_fax_file

Puts a PDF from the person’s own disk on their XipFax draft. A photo of any kind, such as a JPEG, PNG, HEIC, WebP, GIF or AVIF, goes as a PDF made from it first on their computer, upright as a photo viewer shows it: on a Mac, sips -Z 2100 -s format pdf <photo> --out <name>.pdf makes one, upright and at most 2,100 pixels on its long side. Any other kind of file, such as a Word file, goes once saved as a PDF. Work out the PDF’s size in bytes and its SHA-256 first, with a command such as shasum -a 256 <file>, and give both. The answer is an address good for 15 minutes and the headers to send with the file: PUT the file’s exact bytes there with each of those headers, such as with curl --upload-file <file> -H "<name>: <value>" "<address>", then call finish_fax_file. The address takes this file alone. PDFs only, 40 MB at most.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "size_bytes": "<size_bytes>",
      "sha256": "<sha256>"
    },
    "name": "add_fax_file"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Its name, such as its file’s: 255 characters at most.
`sha256`	Yes	Its SHA-256 in hex, 64 characters, as `shasum -a 256 <file>` prints it.
`size_bytes`	Yes	Its size in bytes: a PDF of 40 MB at most.

Output Schema

Name	Required	Description	Default
`upload`	Yes	Where the file goes: a PUT of its exact bytes to `url`, with each of these `headers`, within 15 minutes. It takes this one file and no other.
`document`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that the result is an upload address valid for 15 minutes plus required headers, that the address accepts this single file only, the PDF-only and 40 MB limits, and that finish_fax_file must be called afterwards. These are exactly the operational facts an agent needs to complete the two-step upload.

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?

Front-loaded with the action, then ordered preparation, invocation, and follow-up, which reads well. It is dense and includes platform-specific detail (the exact `sips` invocation, curl example) that borders on bloat, though each piece is actionable rather than filler.

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?

Covers the full task lifecycle for a non-obvious two-step upload tool: input preparation, format constraints, limits, return payload, and the required follow-up call. Even though an output schema exists, the description's explanation of the address/headers is what makes the flow usable.

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 real meaning: it explains that size_bytes and sha256 must be computed from the finished PDF and gives concrete commands (`shasum -a 256 <file>`) plus the 40 MB ceiling. The `name` parameter is only loosely addressed (file naming vs. display name).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Puts a PDF from the person's own disk on their XipFax draft.' The phrase 'their own disk' implicitly distinguishes it from add_fax_file_from_url without naming that sibling, so an agent can infer the split but not with total certainty.

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?

Gives a clear sequential workflow: prepare a PDF, compute size and SHA-256, call this tool, PUT bytes to the returned address, then call finish_fax_file. It does not explicitly state when to prefer add_fax_file_from_url instead, nor whether this must precede finish_fax_file in all cases, so no explicit exclusion/alternative rule.

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

All XipFax 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?