Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

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

0 this week 77 Trust /100
Trust breakdown (7 categories)

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
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
Install

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

# add to Claude Code
claude mcp add xfuel-lab-xfuel-mcp -- npx -y xfuel-mcp
// .cursor/mcp.json
{
  "mcpServers": {
    "xfuel-lab-xfuel-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "xfuel-mcp"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "xfuel-lab-xfuel-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "xfuel-mcp"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add xfuel-lab-xfuel-mcp -- npx -y xfuel-mcp
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "xfuel-lab-xfuel-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "xfuel-mcp"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add xfuel-lab-xfuel-mcp --command npx --arg -y --arg xfuel-mcp
# ~/.hermes/config.yaml
mcp_servers:
  xfuel-lab-xfuel-mcp:
    command: "npx"
    args: ["-y", "xfuel-mcp"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "xfuel-lab-xfuel-mcp": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "xfuel-mcp"
      ]
    }
  }
}
# add to Vellum
assistant mcp add xfuel-lab-xfuel-mcp -t stdio -c npx -a -y xfuel-mcp
// mcp.json
{
  "mcpServers": {
    "xfuel-lab-xfuel-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "xfuel-mcp"
      ]
    }
  }
}
Changelog

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
Diagnostics

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 →

MCP tools · 8 exposed · ~1,858 tokens

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 →

Tool Tokens
get_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 ~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'.

NameTypeReqDescription
task_idstringyesTask id from submit_inference

No output schema declared.

No examples provided.

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'.

NameTypeReqDescription
task_idstringyesTask id from submit_inference

No output schema declared.

No examples provided.

list_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 ~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.

NameTypeReqDescription
amountstringyesGross task value in smallest unit (wei); min 10000
callback_urlstringWebhook for signed TaskSettled event
chain_idstringSettlement network (default theta)
input_hashstringkeccak256 of your input
max_gpu_hoursstringCompute budget hint
memostringFree-form note
modelstringyesModel id, e.g. "llama-3-70b"
senderstring0x address that owns the task (default: payer wallet)
subnet_idintegerBittensor subnet id

No output schema declared.

No examples provided.

quote_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 } } }.

NameTypeReqDescription
amountstringTFUEL task value in wei
model_idstringModel id to price

No output schema declared.

No examples provided.

submit_inference ~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.

NameTypeReqDescription
amountstringyesGross task value in smallest unit (wei); min 10000
callback_urlstringWebhook for signed TaskSettled event
chain_idstringSettlement network (default theta)
input_hashstringkeccak256 of your input
max_gpu_hoursstringCompute budget hint
memostringFree-form note
modelstringyesModel id, e.g. "llama-3-70b"
senderstringyes0x address that owns/pays for the task
subnet_idintegerBittensor subnet id

No output schema declared.

No examples provided.

verify_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'.

NameTypeReqDescription
check_nullifierbooleanAlso read the on-chain nullifier state (needs RPC + zkVerifier configured)
task_idstringyesTask id from submit_inference

No output schema declared.

No examples provided.

Common questions

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.