mayarin
GET
/x402/resources/{id}/payment-required

The price and rails, without making the call being decided about. Not part of the x402 specification — the price normally rides a 402 — but a client deciding whether to pay should not have to make the call first.

Path Parameters

id*string

Response Body

application/json

application/json

curl -X GET "https://example.com/x402/resources/string/payment-required"
{  "x402Version": 0,  "error": "string",  "resource": {    "url": "string",    "description": "string",    "mimeType": "string"  },  "accepts": [    {      "scheme": "string",      "network": "string",      "amount": "string",      "asset": "string",      "payTo": "string",      "maxTimeoutSeconds": 0,      "extra": {        "property1": null,        "property2": null      }    }  ],  "extensions": {    "property1": null,    "property2": null  }}

The MCP server — free discovery, paid tools/call

An MCP server over the same rail, speaking JSON-RPC 2.0. `initialize` and `tools/list` are free; `tools/call` costs one authorization and answers `402` until it carries one. Discovery is free and answers are paid by design: an agent cannot decide a price is worth paying for a tool it has not been allowed to read the description of. Two tools. `rail_stats` reports samples, median headroom, and the worst and best observed per rail; `choose_rail` ranks them and returns the one to pay on. Three refusals never charge — arguments the tool will not accept (refused **before** the gate, since a response cannot be un-served), no settlements observed at all, and a tool that does not exist, which is a tool error rather than a JSON-RPC error so a model can tell 'the server said no' from 'the call never arrived'. Send the **same body** in both the request that receives the `402` and the retry carrying the signature; a different one is a different purchase settled against the first one's authorization. A JSON-RPC notification (no `id`) is answered `202` with no body.

Would this authorization go through?

Checks the signature against the chain without broadcasting. The body's `paymentRequirements` is not what gets verified — Mayarin rebuilds the requirements from the resource and uses the carried copy only to identify which quoted option the payer chose. A facilitator that verified against the requirements handed to it would verify a payment against its own claims.