Flario

Flario

An MCP server for Flare Network. Flario gives an AI agent (in Claude, Cursor, VS Code, or any Model Context Protocol client) plain-language access to Flare's enshrined protocols: FTSO price feeds, FDC cross-chain attestations, and FAssets. It also gives the agent a wallet. Premium tools are paid per call with x402 settled on Flare, and every payment comes back with a receipt the chain itself can prove.

Install it with npx flario, or run it as an HTTP hub. It works against the public Flare RPCs out of the box, needs no account or key for reads, and never holds or forwards funds.

Flario covers the whole enshrined stack: FTSO prices (including proof-carrying anchor feeds), FDC attestation workflows with local Merkle-proof verification, deep FAssets state (per-agent collateral, liquidation risk, system totals, the redemption queue), a Flare portfolio read (delegation, vote power, claimable rewards), Songbird and Coston support, and a watcher for Flare Confidential Compute contracts. Reads are trust-minimized: FDC and FTSO proofs are checked locally against the on-chain Relay root, never taken from an API on faith. The one write, fdc_request_attestation, only submits a transaction if you set FLARE_PRIVATE_KEY; otherwise it hands you a prepared request to sign yourself.

This is complementary to Flare's official MCP server, not a replacement. Their server (dev.flare.network/mcp) does documentation search, so it gives an agent knowledge. Flario gives an agent hands and a wallet: it calls the enshrined protocols and lets the agent pay for computed results, with receipts the chain can verify. Use both.

Where this sits in the x402 ecosystem

Flario speaks the standard x402 wire format, so it is not a private dialect. Payment requirements come back in the usual shape, the payment payload travels base64-encoded in the X-Payment header on the HTTP hub, and the settlement summary comes back in X-Payment-Response. An existing x402 client can pay a Flario endpoint without knowing anything about MCP, and an MCP agent can pay without knowing anything about HTTP.

What Flario adds on top is a proof layer. In a typical x402 deployment, the client learns that a payment settled because the facilitator says so and points at a transaction. Because Flare has a data connector enshrined in the chain, Flario can go further: fdc_verify_settlement obtains an FDC attestation over the settlement transaction, verifies the Merkle proof locally against the on-chain Relay root, and binds it to the actual ERC-20 transfer, so the receipt stands on its own without trusting the facilitator. That step depends on a protocol built into the chain, which is why it is hard to port elsewhere.

DELICTI: mandate before act

flario is the first effector that speaks DELICTI. A paying agent may add mandate_id (and optionally mandate_registry) to its x402 payload; the server binds it into the receipt (flario-receipt/2, field mandate_ref) so any third party can check the deed against an on-chain mandate and, with Flare's FDC as second witness, prove a receipt false or a budget exceeded.

Optional brake — set on the server:

DELICTI_REGISTRY=0x…        # MandateRegistry address on X402_NETWORK

DELICTI_REQUIRE_MANDATE=1 # refuse payments that carry no mandate_id

With DELICTI_REGISTRY set, a payment whose mandate is not live, or whose payer is not the mandated agent, is refused before any funds move. Nothing here touches the EIP-712 authorization; a wrong mandate can never move funds, only get the deed refused or later proven false.

Why Flario

• It goes deep on the protocols that are built into Flare. FTSO, FDC, and FAssets are enshrined in the chain, and so are Flario's 24 tools. A generic multi-chain MCP server can't reach any of this, and the depth doesn't port to another chain.
• Answers carry a proof, so you don't have to take my word for it. Prices and cross-chain facts come with a Merkle proof that Flario checks locally against the on-chain root. An agent, or even a smart contract, can rely on the answer without trusting any API.
• Agents can pay, and they get a receipt. Premium tools settle per call over x402 on Flare, and each payment returns a portable receipt that Flare's own FDC can prove, not just the facilitator's word for it. No other chain in the x402 ecosystem can do that today.
• Self-hostable, no custody. It runs on public RPCs, asks for no account or key to read data, and never touches your funds.

Examples

Once Flario is in your MCP client (see Install), you just ask in plain language:

A proof-carrying price comes back with the value and a proof the agent can verify on its own (trimmed):

{

"verified": true, "verification": "Local: keccak256(abi.encode(feed body)) folded through the Merkle proof equals Relay.merkleRoots(100, round) read on-chain.", "name": "FLR/USD", "price": 0.006786, "voting_round_id": 1402671, "merkle_root": "0x...", "proof": ["0x...", "0x..."] }

Install

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows) and add:

{

"mcpServers": { "flario": { "command": "npx", "args": ["-y", "flario"], "env": { "FLARE_RPC": "https://flare-api.flare.network/ext/C/rpc", "FLARE_RPC_TESTNET": "https://coston2-api.flare.network/ext/C/rpc" } } } }

Restart Claude Desktop, then ask something like "What's the FLR/USD price on Flare?" or "How much FXRP is minted right now?".

Cursor

Edit ~/.cursor/mcp.json (global) or .cursor/mcp.json (per project) and add:

{

"mcpServers": { "flario": { "command": "npx", "args": ["-y", "flario"] } } }

The same block works in any MCP client with stdio support (VS Code, Windsurf, Zed, and so on). The env block is optional, since the public Flare RPCs are used by default.

Check it works (no client, ~10 s)

# List all 24 tools straight from the published package:

npx -y @modelcontextprotocol/inspector --cli npx -y flario --method tools/list

Or call one, a proof-carrying FLR/USD price on mainnet:

npx -y @modelcontextprotocol/inspector --cli npx -y flario \ --method tools/call --tool-name get_ftso_anchor_feed \ --tool-arg feed_id=FLR/USD --tool-arg network=mainnet

Start here: seven prompts, no Flare knowledge required

Tools answer questions. Prompts tell you what to ask in the first place. Flario ships seven, and they show up in your MCP client's prompt list once it is connected — in Claude Desktop, the + menu in the message box.

Every prompt instructs the model to run the calls for real against the live network and then explain what happened, so you end up with actual numbers and a mental model at the same time. They are deliberately written to admit when something is not live yet rather than talk around it.

Watch Flare 2.0 arrive

Flare's confidential compute is being deployed right now, one network at a time, and Flare has not published an ABI for it — FlareTeeManager is absent from the periphery artifacts, alpha releases included. fcc_deployment_status reads it anyway, because the interesting facts do not need an ABI.

As of 1 September 2026 it reports:

Confidential compute is registered on: coston.

Not yet on: mainnet, songbird, coston2.

coston: FlareTeeManager @ 0xc4885998f5D792ed88C5Af7a3AaCBe333f017658 ERC-2535 diamond, 18 facets, 198 selectors, 0 unrecognised live state: 11 governance signers, machine allowlist revised 4 times fdc2Hub() -> 0x064C7B68B0e2BC87e7bE34e89741485Fcb48FA2F (has code) fdc2Verification() -> 0x21D3842E39A3b62ba15CD8A5D2ED5cEDea931502 (has code)

The capabilities come out of the selectors: Protocol Managed Wallets, remote attestation of TEE machines and their code hashes, multi-signature governance over the machine allowlist, randomness generated inside the enclave, and FDC V2 wiring.

Why selectors instead of function calls

A tool built on guessed function signatures breaks the moment Flare finalises the interface. Selectors are the routing table inside the diamond — they are facts on-chain, and a rename does not move them. So the tool reports what is exact (facets, selectors, addresses, wiring, governance state) and flags what is inferred: human-readable names come from a public signature database, and the report says so every time it prints one. All 198 resolved and are thematically coherent, which makes the mapping almost certainly right, but "almost certainly" is what gets printed rather than something firmer.

This is a testnet deployment of an unfinished system and anything in it can change. That is the point of a monitor rather than an integration.

Prove what an agent acted on

Every other tool here verifies a fact at the moment you ask, and then that verification evaporates — it survives as a sentence in a tool response nobody can re-check later. Evidence bundles close that gap.

evidence_bundle collects proof-carrying facts into one portable object. evidence_verify is the receiving end: it rebuilds every leaf from its own body, folds it through its Merkle proof, and compares the result against Relay.merkleRoots(protocol, round) read on-chain right then. The person verifying does not have to