An AI agent can help someone prepare a fax, but the last thing we want is for a tool call to quietly send a document or charge a card. FaxOnline's agent workflow splits that job into preparation, a checkout the person reviews, and status checks after authorization.
We expose the same backend through two routes into the product: a remote MCP server for agent clients, and WebMCP tools registered by the site for compatible browser agents. The public MCP endpoint uses Streamable HTTP at /mcp/fax. It needs no API key; a request origin check and rate limit protect the endpoint. A server manifest at /mcp.json, a connection guide, and an agent skill explain how to connect and use it.
Prepare first, send after checkout
The server provides two tools. prepare_fax accepts a US fax number, email, PDF filename, base64 PDF, and a private 64-character random draft token. The service validates the file and destination, stores the PDF privately, calculates the server-side price, and returns a Stripe Checkout link. Preparing a fax does not send it or charge the user.
That token is the key to making retries safe without exposing a fax record identifier. The server stores its hash, binds it to a hash of the fax details and document, and uses a lock and Stripe idempotency key while creating the draft and checkout. Repeating the same request returns the existing draft; trying different inputs with the same token is rejected. The agent guidance tells clients to keep the token secret and reuse it only with identical inputs.
Checkout is the user's decision point. Once Stripe verifies authorization, the application queues transmission. Payment capture happens after successful delivery. The second tool, get_fax_status, uses the same private token and returns payment and delivery state. Instructions cap polling at once every 15 seconds, distinguish processing from delivered, and warn against creating another fax when a provider submission is uncertain.
WebMCP uses the same tools
On page load, the site's JavaScript checks for the browser's model context API. If present, it first asks the MCP endpoint for its tool list, then registers the fax preparation and status tools using the server-provided schemas. Calls go back to /mcp/fax, so browser agents share the same validation and backend behavior as remote MCP clients.
The browser integration also offers get_fax_pricing, which reads the public pricing document, and start_fax, which opens the regular send form. If MCP discovery is unavailable, those two browser tools can still be registered when the browser supports WebMCP. If the browser has no compatible API, the script exits without making a request. Tool errors are returned to the agent rather than retried automatically, and request cancellation is passed through.
This arrangement keeps the fax workflow in one place while making it discoverable both from an MCP client and from a browser page. The practical constraint is client support: remote MCP and WebMCP availability varies by agent and browser, so the ordinary send form remains available too.