XFuel
NPM · XFUEL-MCP · SCANNED SEP 20
Submit AI inference to XFuel, pay per task (USDC via x402 or TFUEL), fetch/verify ZK proofs.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security98
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 35 of 119 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency23
- Repository check failed: the declared repository URL redirects; it must resolve directly. See how to fix → View diagnostics → Fail
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (Apache-2.0).Pass
- Actively maintained (last published 14 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability68
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 1858 tokens (~232/item across 8 items; 8 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management93
- Stability observed for 28 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 8 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the XFuel MCP server?
XFuel runs locally as an npm package, launched with npx -y xfuel-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · xfuel-mcp
claude mcp add xfuel-lab-xfuel-mcp -- npx -y xfuel-mcp
{
"mcpServers": {
"xfuel-lab-xfuel-mcp": {
"command": "npx",
"args": [
"-y",
"xfuel-mcp"
]
}
}
} {
"servers": {
"xfuel-lab-xfuel-mcp": {
"command": "npx",
"args": [
"-y",
"xfuel-mcp"
]
}
}
} codex mcp add xfuel-lab-xfuel-mcp -- npx -y xfuel-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"xfuel-lab-xfuel-mcp": {
"type": "local",
"command": [
"npx",
"-y",
"xfuel-mcp"
],
"enabled": true
}
}
} openclaw mcp add xfuel-lab-xfuel-mcp --command npx --arg -y --arg xfuel-mcp
mcp_servers:
xfuel-lab-xfuel-mcp:
command: "npx"
args: ["-y", "xfuel-mcp"] {
"McpServers": {
"xfuel-lab-xfuel-mcp": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"xfuel-mcp"
]
}
}
} assistant mcp add xfuel-lab-xfuel-mcp -t stdio -c npx -a -y xfuel-mcp
{
"mcpServers": {
"xfuel-lab-xfuel-mcp": {
"command": "npx",
"args": [
"-y",
"xfuel-mcp"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 19 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.
- 17 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 16 Sept 26 −3
- Stability: pass → 0.80 functional
- 15 Sept 26 0
- Stability: 0.97 → pass security
- 14 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.
- 12 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.
- 10 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 9 Sept 26 −3
- Stability: pass → 0.80 functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Sept 2026 · Analysed npm/xfuel-mcp@0.1.1
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | npm |
Background: How many MCP packages publish verified provenance →
Dependencies 119 packages
| Packages resolved | 119 |
|---|---|
| Stale | 35 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
get_health Get XFuel API health ~67
Check the connected XFuel API's health and configuration (fee config, supported chains, message types, demo limits). Useful for discovery/diagnostics. Args: none. Returns JSON: the /health payload (status, server, version, fee_config, chains, message_types, …).
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_proof Get ZK settlement proof ~145
Fetch the SP1 ZK settlement proof for a settled task. Args: - task_id (string): the id returned by submit_inference Returns JSON: { task_id, status, proof_outcome, payment_binding, sp1_proof: { proof, publicInputs, nullifier, provingTimeMs }, fee }. The proof attests settlement metadata + a commitment to the output hash (NOT inference correctness). To validate it, use verify_proof(task_id). Fails if the task has not settled yet — poll get_task_status until proof_outcome is 'valid'.
| Name | Type | Req | Description |
|---|---|---|---|
| task_id | string | yes | Task id from submit_inference |
No output schema declared.
No examples provided.
get_task_status Get task status ~155
Get the current status of an XFuel task, including proof outcome and fee breakdown. Args: - task_id (string): the id returned by submit_inference Returns JSON: { task_id, status, proof_outcome, message_type, chain_id, gross_amount, fee_amount, net_amount, fee_bps, payment_rail, payment_ref, result, sp1_proof, created_at, updated_at }. 'status' reaches a terminal value ('completed' | 'fee_collected' | 'failed'); 'proof_outcome' is one of 'pending' | 'valid' | 'regenerable' | 'invalid'.
| Name | Type | Req | Description |
|---|---|---|---|
| task_id | string | yes | Task id from submit_inference |
No output schema declared.
No examples provided.
list_models List routable models ~88
List the models XFuel can route inference to (OpenAI-compatible GET /v1/models). Call this first to discover valid model ids, then pass one as 'model' to submit_inference or pay_with_usdc. No side effects. Args: none. Returns JSON: { object: 'list', data: [{ id, object: 'model', created, owned_by }] }.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
pay_with_usdc Submit + pay for inference with USDC (x402) ~556
Submit an AI inference task and settle it with USDC via x402 (the default XFuel rail). The server signs an EIP-3009 USDC authorization on Base with its configured payer wallet, so the agent doesn't manage the handshake. If the server has x402 disabled it transparently falls back to the TFUEL rail (no payment is made). Requires the server to be started with XFUEL_PAYER_PRIVATE_KEY. If it is not set, this tool returns a clear "not configured" message — use submit_inference (TFUEL) instead, or the xfuel-sdk with your own payer. The USDC network is chosen by the server's x402 challenge (the payer signs for whatever network the challenge specifies, e.g. Base or Base Sepolia). Args: - model (string): model id, e.g. "llama-3-70b" - amount (string): gross task value in the smallest unit (wei); minimum 10000 - sender (string, optional): the 0x address that owns the task (default: the payer wallet address) - chain_id ('theta'|'bittensor'|'akash'|'osmosis'|'persistence'): settlement network (default 'theta') - input_hash (string, optional): keccak256 of your input (recommended for inference) - memo (string, optional): free-form note echoed on the task - max_gpu_hours (string, optional): compute budget hint - subnet_id (number, optional): Bittensor subnet id when chain_id='bittensor' - callback_url (string, optional): webhook that receives a signed TaskSettled event Returns JSON: { task_id, status, payment_rail, fee_bps, gross_amount, fee_amount, net_amount, links }. 'payment_rail' is 'usdc' when the x402 handshake ran, or 'tfuel' if the server fell back.
| Name | Type | Req | Description |
|---|---|---|---|
| amount | string | yes | Gross task value in smallest unit (wei); min 10000 |
| callback_url | string | – | Webhook for signed TaskSettled event |
| chain_id | string | – | Settlement network (default theta) |
| input_hash | string | – | keccak256 of your input |
| max_gpu_hours | string | – | Compute budget hint |
| memo | string | – | Free-form note |
| model | string | yes | Model id, e.g. "llama-3-70b" |
| sender | string | – | 0x address that owns the task (default: payer wallet) |
| subnet_id | integer | – | Bittensor subnet id |
No output schema declared.
No examples provided.
quote_task Quote / price a task ~150
Preview per-rail pricing for a task WITHOUT creating it (no side effects). Use this before submit_inference to show the user cost across payment rails. Args: - model_id (string, optional): model id to price (some models have overrides) - amount (string, optional): TFUEL task value in wei (echoed back in the tfuel rail) Returns JSON: { recommended, default_rail, rails: { usdc: { enabled, asset, network, decimals, amount, pay_to }, tfuel: { amount } } }.
| Name | Type | Req | Description |
|---|---|---|---|
| amount | string | – | TFUEL task value in wei |
| model_id | string | – | Model id to price |
No output schema declared.
No examples provided.
submit_inference Submit AI inference task ~455
Submit an AI inference task to the XFuel Protocol. XFuel routes it to a GPU provider (Theta EdgeCloud → DePIN fallbacks), and settles with a ZK proof. Args: - model (string): model id, e.g. "llama-3-70b" - sender (string): the 0x address that owns/pays for the task - amount (string): gross task value in the smallest unit (wei); minimum 10000 - chain_id ('theta'|'bittensor'|'akash'|'osmosis'|'persistence'): settlement network (default 'theta') - input_hash (string, optional): keccak256 of your input (recommended for inference) - memo (string, optional): free-form note echoed on the task - max_gpu_hours (string, optional): compute budget hint - subnet_id (number, optional): Bittensor subnet id when chain_id='bittensor' - callback_url (string, optional): webhook that receives a signed TaskSettled event Returns JSON: { task_id, status, payment_rail, fee_bps, gross_amount, fee_amount, net_amount, links }. Poll progress with get_task_status(task_id); fetch settlement with get_proof(task_id). Note: this submits with the server's default (unpaid/TFUEL) rail. For USDC/x402 settlement (which needs an agent-side signer) use the xfuel-sdk directly.
| Name | Type | Req | Description |
|---|---|---|---|
| amount | string | yes | Gross task value in smallest unit (wei); min 10000 |
| callback_url | string | – | Webhook for signed TaskSettled event |
| chain_id | string | – | Settlement network (default theta) |
| input_hash | string | – | keccak256 of your input |
| max_gpu_hours | string | – | Compute budget hint |
| memo | string | – | Free-form note |
| model | string | yes | Model id, e.g. "llama-3-70b" |
| sender | string | yes | 0x address that owns/pays for the task |
| subnet_id | integer | – | Bittensor subnet id |
No output schema declared.
No examples provided.
verify_proof Verify a task proof ~242
Independently verify a settled task's proof client-side (the "prove it" flow in one call): 1. a proof is present and proof_outcome === 'valid'; 2. the x402 payment binding (if present) re-derives to the committed value; 3. (optional) the on-chain nullifier's spent state, when check_nullifier=true AND the server was started with XFUEL_RPC_URL + ZK_VERIFIER_ADDRESS. Args: - task_id (string): the id returned by submit_inference - check_nullifier (boolean, optional): also read the on-chain nullifier state (default false) Returns JSON: { ok, checks: { hasProof, proofOutcomeValid, paymentBinding, nullifier }, reasons }. 'ok' is true when the proof is present + valid and any present payment binding is consistent. The nullifier read is informational and does not gate 'ok'.
| Name | Type | Req | Description |
|---|---|---|---|
| check_nullifier | boolean | – | Also read the on-chain nullifier state (needs RPC + zkVerifier configured) |
| task_id | string | yes | Task id from submit_inference |
No output schema declared.
No examples provided.
What is the XFuel MCP server?
XFuel is an MCP server listed in the public MCP registry as io.github.XFuel-Lab/xfuel-mcp. Submit AI inference to XFuel, pay per task (USDC via x402 or TFUEL), fetch/verify ZK proofs. This page covers its npm package (xfuel-mcp).
Is the XFuel MCP server safe to use?
XFuel scores 77 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the XFuel MCP server expose?
XFuel exposes 8 tools: submit_inference, pay_with_usdc, get_task_status, get_proof, verify_proof, and 3 more. Their descriptions and schemas cost roughly 1,858 tokens of context every time the server is loaded.
Is the XFuel MCP server still maintained?
XFuel is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the XFuel MCP server under?
XFuel declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.