Faxette EU

Send a fax from credit

send_fax

Destructive

Use this to send a fax from the person's Faxette credit. Only for a fax in their account that's ready to pay for: call get_fax first. Tell the person its credit_price and that it comes from their credit, and call this only once they clearly agree. If get_account shows their credit doesn't cover it, give them the status page instead, where they can buy credit or pay by card. Needs the person to sign in to Faxette; calling it while they aren't asks the app to sign them in.

Input Schema

Name	Required	Description	Default
`id`	Yes	The fax's id, from create_fax, get_faxes or get_fax.
`amount_cents`	Yes	The credit_price amount_cents from get_fax that the person agreed to. If the fax's documents changed since, Faxette refuses with price_changed: call get_fax and confirm the new price.

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.
`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.
`status_url`	Yes	The page where the person checks the fax and pays. Give it to them.
`max_attempts`	Yes
`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.

First observedOct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations flag destructiveHint/openWorldHint, and the description adds the critical facts beyond them: this spends real credit, consent must be explicit, and invoking while unauthenticated triggers a sign-in flow rather than failing. That is exactly the behavioral context annotations cannot convey.

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?

Purpose and funding source are front-loaded, followed by prerequisites and the fallback path in logical order with no filler. It is slightly dense with multi-clause sentences where a two-line structure would read faster, but every sentence carries information.

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 a monetary, non-idempotent mutation with an output schema, the description covers consent requirements, prerequisite reads, authentication needs, and the insufficient-credit fallback. Nothing an agent needs before calling is missing.

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% and both parameters are documented in detail, including the price_changed refusal path for amount_cents. The description reinforces the workflow (confirm price via get_fax before calling) but adds no syntax or value semantics the schema lacks, so baseline 3 applies.

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 and resource ('send a fax') plus the funding source ('from the person's Faxette credit'), which is the exact distinction from siblings like create_fax. An agent can tell this apart from fax creation without opening the schema.

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 preconditions and sequencing: call get_fax first, confirm credit_price, obtain clear agreement, call only once. It also names the alternative path (status page) when get_account shows insufficient credit, and routes to get_account for the check.

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

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