Faxette

Resend an eligible failed fax

resend_fax

Destructive

Use this only after the person asks to resend a failed fax and confirms its destination, including any corrected number. Check get_fax or get_fax_status first. Reuses the existing fax, payment hold and resend rules; it does not create a new paid fax. Faxette refuses expired resend windows and exhausted retries. If a call is interrupted, check the existing fax before calling again.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "resend_fax"
  }
}

Input Schema

Name	Required	Description
`id`	No	An account fax ID; requires sign-in. Pass this or status_url, not both.
`fax_number`	No	A corrected number explicitly confirmed by the person. Omit to use the existing destination.
`status_url`	No	The original fax status link, including its token for a guest fax.

Output Schema

Name	Required	Description
`id`	Yes	The fax's id. Pass it to get_fax when the person is signed in.
`price`	Yes	Before tax. Null until the pages are counted.
`status`	Yes	draft: waiting for files, or for a file to be fixed. processing_documents: counting pages. documents_ready: ready to pay. awaiting_payment: the person is paying. scheduled: paid, about to dial. sending, delivered, failed. canceled: not paid in time.
`attempt`	Yes	The current attempt to dial the fax number.
`payment`	Yes	The person's payment once they start paying, by card or from their credit. amount_cents includes tax.
`language`	No
`resend_by`	Yes	For a failed fax: until when the person can correct the fax number on the status page and send it again.
`fax_number`	Yes
`page_count`	Yes	Null until the pages are counted.
`review_url`	No	A private review link, valid for 30 minutes. Give it to the person so they can inspect the prepared PDF before paying.
`status_url`	Yes	The page where the person checks the fax and pays. Give it to them.
`max_attempts`	Yes
`checkout_quote`	No
`failure_reason`	Yes	For a failed fax: temporary (busy or no answer on every attempt), wrong_number (no fax machine answered), or our_side.
`document_errors`	Yes	Files Faxette couldn't use. position is the file's number in the fax. The person fixes them on the status page.
`next_attempt_at`	Yes	When the next attempt dials, if the line was busy or didn't answer.
`checkout_available`	Yes	True when the person can pay on the status page.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, it discloses that the tool reuses the existing fax and payment hold, does not create a new paid fax, refuses expired resend windows, and refuses exhausted retries. These are meaningful behavioral constraints for a destructive, non-idempotent action, and the interrupted-call warning reinforces the non-idempotent nature.

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?

It is front-loaded with the key precondition, followed by the required checks, then behavioral consequences and failure modes. Every sentence adds operational value, and there is no redundant 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?

Given an output schema, complete parameter coverage, and annotations covering safety traits, the description fills the remaining gaps: when to use it, what to check first, what gets reused, and when the tool will refuse. An agent has enough information to invoke it correctly.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds context that fax_number should be an explicitly confirmed corrected number and that the destination must be confirmed, but it largely restates information already present in the 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?

It names a specific verb and resource (resend a failed fax) and explicitly contrasts the operation with creating a new paid fax, which distinguishes it from send_fax and create_fax. The title reinforces eligibility, and the description makes clear that the existing fax is reused.

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?

It states a precise precondition (the person asks and confirms the destination, including any corrected number) and names the prerequisite checks get_fax or get_fax_status. It also warns against calling again after an interrupted call without first checking the existing fax.

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

All Faxette 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.