FiatDock

Call any x402 endpoint

call_x402

Call a pay-per-call x402 endpoint from the public index (find it with search_x402) — any host, not only FiatDock listings. TO BUY: call once WITHOUT payment to get the endpoint's 402 decoded (its price, its payTo, the EIP-712 domain) plus step-by-step instructions, sign ONE entry of accepts — the one on a network you can pay — with your own wallet, then call again with the same url/method/body plus payment set to the base64 x402 payload; the money goes straight from your wallet to the endpoint's payTo, FiatDock takes no fee and never touches it. No wallet? npx fiatdock-mcp with AGENT_PRIVATE_KEY and a maxPriceUsd ceiling signs and pays automatically. The endpoint's answer comes back as result with its settlement receipt when it settled. Reaches only hosts the public index lists; a FiatDock listing is called with call_service.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	The endpoint URL from search_x402 (https). Fill any path parameter (e.g. :email) yourself
`body`	No	JSON body to send (default {}). Its shape is the endpoint's — read its description, or the 402's own hint
`method`	No	HTTP method (default POST — most x402 endpoints take a JSON body)
`payment`	No	Base64 of ONE x402 v2 PaymentPayload you signed for ONE entry of the endpoint's accepts (from the first call's 402 — pick the network you can pay). Sent to the ENDPOINT as its PAYMENT-SIGNATURE header, never read by FiatDock. Omit on the first call to receive the challenge

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	true when the endpoint answered 2xx
`url`	Yes	The URL that was called
`hint`	No	Present on a 405: the endpoint refused this HTTP method — call again with the other one (the index records no method)
`note`	No	Present only when truncated
`paid`	Yes	true when a payment header travelled with the request — yours, or one this package signed
`allow`	No	The endpoint's Allow header on a 405, when it sent one
`method`	Yes	GET or POST
`result`	No	The endpoint's response body — parsed JSON when it returned JSON, otherwise the raw text
`status`	Yes	The ENDPOINT's HTTP status (a 402 comes back as isError with the decoded challenge instead)
`truncated`	No	True when the body was cut at 256 KB
`settlement`	No	The endpoint's decoded PAYMENT-RESPONSE header when it settled: the x402 settlement receipt (tx hash, network, payer)

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 21, 2026

addedOutput schema / properties / allow

Added value: +{
+  "description": "The endpoint's Allow header on a 405, when it sent one",
+  "type": "string"
+}

addedOutput schema / properties / hint

Added value: +{
+  "description": "Present on a 405: the endpoint refused this HTTP method — call again with the other one (the index records no method)",
+  "type": "string"
+}

Changed1 schema field changedSep 21, 2026

changedInput schema / properties / payment / description

Previous value: -"Base64 of ONE x402 v2 PaymentPayload you signed for the endpoint's accepts[0] (from the first call's 402). Sent to the ENDPOINT as its PAYMENT-SIGNATURE header, never read by FiatDock. Omit on the first call to receive the challenge"New value: +"Base64 of ONE x402 v2 PaymentPayload you signed for ONE entry of the endpoint's accepts (from the first call's 402 — pick the network you can pay). Sent to the ENDPOINT as its PAYMENT-SIGNATURE header, never read by FiatDock. Omit on the first call to receive the challenge"

AddedSep 21, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations (readOnlyHint=false, destructiveHint=false) already cover the safety profile, and the description goes well beyond them: it discloses the two-call protocol, that money moves directly from the caller's wallet to payTo, that FiatDock charges no fee and never touches funds, and that responses come back as `result` with a settlement receipt. For a tool that triggers real payment, this level of disclosure is essential and fully delivered.

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?

Although long, every sentence earns its place: purpose/scope, buy protocol, no-wallet alternative, response semantics, and reach limitation. The 'TO BUY:' and 'No wallet?' signposts make a complex flow scannable, and the purpose is front-loaded before any procedure. No filler or repetition of annotation content.

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 high-complexity, financially consequential tool, the description covers everything needed to call correctly: source of inputs (search_x402), the exact two-step payment flow, fee transparency, response shape (`result` plus settlement receipt), and the host scope limit. An output schema exists, so return-value details are available structurally, and the description still gives the key semantic. Nothing essential is 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 coverage is 100% and each parameter already has a rich description, so baseline is 3. The description adds genuine protocol-level meaning beyond the schema: it assembles the parameters into a sequence (omit payment → receive 402 → sign one accepts entry → resubmit with payment), clarifies url must come from search_x402, and explains that payment is sent to the endpoint, not read by FiatDock. It earns a 4 but not a 5 because the schema already carries most per-parameter semantics.

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 opener states a specific verb and resource — 'Call a pay-per-call x402 endpoint from the public index' — and immediately separates it from siblings: search_x402 (finding) and call_service (FiatDock listings). The 'any host, not only FiatDock listings' clause makes its scope unmistakable. Nothing about the purpose is left to inference.

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 routing is given in the prose: endpoints come from search_x402, FiatDock listings go to call_service, and the wallet-less path is npx fiatdock-mcp. The 'TO BUY' section lays out the exact call sequence (once without payment, then again with payment). This tells an agent both when to use it and which sibling to pick instead.

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

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