v1.5.0 — evidence bundles

Everything before this verified a fact at the moment you asked, and then the verification evaporated into a sentence nobody could re-check. This release turns a verified fact into something you can hand to someone else.

Two new tools

evidence_bundle packages FTSO Scaling anchor feeds and finalized FDC attestations (Web2Json included) into one portable object carrying each fact's Merkle proof, voting round, protocol id and the Relay address. Every fact is folded against the on-chain root before inclusion — a fact that fails is refused rather than flagged, and a Web2Json fact without expect_source is refused too, since an unbound proof attests to whatever URL sits inside it.

evidence_verify is the receiving end. It rebuilds every leaf from its own body, folds it through its proof, and compares against Relay.merkleRoots(protocol, round) read on-chain at verification time. Nothing in the bundle is trusted, including its own hash. The verifier needs an RPC endpoint and nothing else — not this server, not the DA layer, not the agent that produced the bundle.

The hash is not the security boundary

bundle_hash is tamper-evidence, and it is documented as exactly that. Verified live on mainnet: an attacker who triples a price and recomputes the hash still fails verification, because the proof no longer folds to a root Flare's validators signed.

```
verified: false | bundle_hash_intact: true | facts_failed: 1
reason: the proof does not fold to the on-chain FTSO Scaling root
```

The hash catches accidents. Consensus catches attackers.

What a bundle does not prove

Not that the agent was honest about its reasoning, not that these were the only facts it saw, not that its conclusion follows. Only that these specific facts were true, in these rounds. That is a narrower claim than "audit trail", and it is a different claim from attesting that a server executed correctly — which still requires trusting the operator or their hardware.

New prompt prove_what_you_acted_on walks through building a bundle, verifying it, then forging it two ways and watching both get caught.

23 tools, 6 prompts, 2 resources, 103 tests.

v1.4.1 — prompts, two stubs turned real, CI

Flario is now in the official MCP Registry as io.github.dziuba0x/flario.

Five prompts, no Flare knowledge required

Tools answer questions. Prompts tell you what to ask. These show up in your client's prompt list and drive real calls against the live network:

• Show me what Flare can do — a guided tour: a price, the same price carrying a proof you verify locally, FAssets state
• Verify a price without trusting anyone — walks through exactly what earned the verified: true: which leaf, which fold, which contract the root came from
• Turn a web API into a provable fact — Web2Json end to end, including the trap that a valid proof only proves the data came from the URL inside it
• Check FAssets system health — live agent collateral against live prices
• Why Flare, for someone building agents — the case for and against, including where the ecosystem is weak

Two stubs are now real tools

• get_ftso_providers used to fail on install unless you pointed it at an indexer that does not exist publicly. It now reads the VoterRegistry directly and ranks providers by share of normalised vote weight. 100 providers on mainnet, 65 on Songbird, no external service.
• get_smart_account_info guessed at a `getFlareAddress` function that does not exist. It now uses `getPersonalAccount` and `isSmartAccount` from the published interface, resolves both directions, and distinguishes a reserved address from a deployed one.

Infrastructure

• CI on Node 20, 22 and 24, plus a cold-start job that spawns the built server over stdio with no env vars — the exact path a new user's client takes on first run
• `server.json` and `mcpName` for registry ownership validation
• `live-check` reports stale verifier fixtures as SKIP instead of failing the run

21 tools, 5 prompts, 2 resources, 96 tests.