Celo x402 Facilitator
Check supported assets and verify x402 payments on Celo
Should I use this
Quality & Safety
Based on automated analysis of tool definitions and protocol compliance.
Context Cost
This is the approximate number of tokens consumed each time the server's tools are loaded into a model's context. Higher counts reduce the attention available for other tasks.
Install
One-Click Install
Add this to your `claude_desktop_config.json` file:
{
"mcpServers": {
"x402-facilitator": {
"url": "https://api.x402.celo.org/mcp"
}
}
}Remote endpoints
https://api.x402.celo.org/mcpstreamable-httpWhat it can do
Tool inventory
Tools (5)
🟢get_supported
The (x402Version, scheme, network) kinds and extensions this facilitator verifies and settles. Same answer as GET /supported.
Input Schema
{
"type": "object",
"properties": {},
"additionalProperties": false
}🟢get_config
Every settleable asset with its address, decimals, transfer method and EIP-712 domain values, plus the pricing model (gas at cost, plus a fee in basis points on the payment value when the asset has a USD price), the gas fallback and the free-credit allowances. Same answer as GET /api/config.
Input Schema
{
"type": "object",
"properties": {},
"additionalProperties": false
}🟢get_health
Whether the facilitator behind this host is answering. Same answer as GET /health.
Input Schema
{
"type": "object",
"properties": {},
"additionalProperties": false
}🟢verify_payment(x402Version, paymentPayload, paymentRequirements)
Check a signed x402 payment against its requirements: signature, amount, balance and simulation. Moves no funds. Same answer as POST /verify, and it spends the same per-IP allowance.
Input Schema
{
"type": "object",
"properties": {
"x402Version": {
"type": "integer",
"description": "x402 protocol version of the payload, e.g. 2."
},
"paymentPayload": {
"type": "object",
"description": "The PaymentPayload the buyer signed."
},
"paymentRequirements": {
"type": "object",
"description": "The PaymentRequirements the resource server stated."
}
},
"required": [
"paymentPayload",
"paymentRequirements"
]
}🟢payment_status(asset, payer, nonce, validBefore)
Whether a signed payment authorization has been used on chain, for a client whose settle reply was lost. Answers unspent, consumed or expired from the chain (EIP-3009 authorizationState, or the Permit2 nonce bitmap). unspent is not final: the authorization can still be used until validBefore, and a settlement already in flight reads as unspent here. Only consumed and expired are final; expired is only reported 5 s after validBefore, so a payment still in flight is not called final. The settled and pending states need the owning API key and are only served over HTTP. Same answer as GET /settle/status, and it spends the same per-IP allowance.
Input Schema
{
"type": "object",
"properties": {
"asset": {
"type": "string",
"description": "Token address the payment was signed for."
},
"payer": {
"type": "string",
"description": "Address that signed the authorization."
},
"nonce": {
"type": "string",
"description": "EIP-3009: the 32-byte hex nonce. Permit2: the nonce as a decimal or 0x-hex uint256."
},
"validBefore": {
"type": "integer",
"description": "Optional. The authorization's validBefore (Permit2: deadline), in unix seconds, so an unused one more than 5 s past it reads as expired."
}
},
"required": [
"asset",
"payer",
"nonce"
],
"additionalProperties": false
}Community
Evidence