Celo x402 Facilitator
Check supported assets and verify x402 payments on Celo
使うべきか
品質と安全性
ツール定義とプロトコルへの準拠に関する自動分析に基づいています。
コンテキストコスト
これは、サーバーのツールがモデルのコンテキストに読み込まれるたびに消費されるおおよそのトークン数です。数が多いほど、ほかのタスクに使える注意が減ります。
インストール
ワンクリックインストール
これを `claude_desktop_config.json` ファイルに追加してください:
{
"mcpServers": {
"x402-facilitator": {
"url": "https://api.x402.celo.org/mcp"
}
}
}リモートエンドポイント
https://api.x402.celo.org/mcpstreamable-httpできること
ツール一覧
ツール（5）
🟢get_supported
The (x402Version, scheme, network) kinds and extensions this facilitator verifies and settles. Same answer as GET /supported.
入力スキーマ
{
"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.
入力スキーマ
{
"type": "object",
"properties": {},
"additionalProperties": false
}🟢get_health
Whether the facilitator behind this host is answering. Same answer as GET /health.
入力スキーマ
{
"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.
入力スキーマ
{
"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.
入力スキーマ
{
"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
}コミュニティ
エビデンス