Celo x402 Facilitator
Check supported assets and verify x402 payments on Celo
¿Debería usar esto?
Calidad y seguridad
Basado en el análisis automatizado de las definiciones de herramientas y el cumplimiento del protocolo.
Costo de contexto
Este es el número aproximado de tokens que se consumen cada vez que las herramientas del servidor se cargan en el contexto de un modelo. Los recuentos más altos reducen la atención disponible para otras tareas.
Instalar
Instalación con un clic
Agrega esto a tu archivo `claude_desktop_config.json`:
{
"mcpServers": {
"x402-facilitator": {
"url": "https://api.x402.celo.org/mcp"
}
}
}Puntos de conexión remotos
https://api.x402.celo.org/mcpstreamable-httpQué puede hacer
Inventario de herramientas
Herramientas (5)
🟢get_supported
The (x402Version, scheme, network) kinds and extensions this facilitator verifies and settles. Same answer as GET /supported.
Esquema de entrada
{
"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.
Esquema de entrada
{
"type": "object",
"properties": {},
"additionalProperties": false
}🟢get_health
Whether the facilitator behind this host is answering. Same answer as GET /health.
Esquema de entrada
{
"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.
Esquema de entrada
{
"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.
Esquema de entrada
{
"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
}Comunidad
Evidencia