About fairseal-mcp-server
fairseal-mcp-server exposes FairSeal’s verifiable randomness and receipt verification to AI agents, for game operators and systems that need auditable randomized outcomes. Its commit-before-outcome model lets results be independently checked.
Key features
- 01Verifiable entropy for selections
- 02Provably fair game outcomes
- 03Cryptographic receipt verification
- 04Commitment before outcome
Use cases
- 01Verify gacha and loot-box drops
- 02Audit randomized matchmaking
- 03Check tournament seeding
- 04Verify NFT mint queues
MCP support
Exposes verifiable entropy, provably fair games, and cryptographic receipt verification to AI agents through MCP.
Configuration
Local server config is the same for every client. Copy it into your client’s MCP config file.
npx -y @fairseal/mcp-serverFAIRSEAL_API_KEYSecretOptional API key sent as Bearer header (live API currently requires no auth; any placeholder works).FAIRSEAL_API_URLUpstream API base URL (default https://api.fairseal.io).Local servers need a runtime on your machine (e.g. Node.js 18+). Config file locations differ by client; see your client’s docs.
Tools
Local servers expose tools only once running on your machine, and the maintainer has not provided a tool list.
Details
From the project READMEFairseal 🦭
Provably fair selections for games, loot boxes, and any randomized allocation.
Fairseal creates verifiable receipts (CSRs) proving that a selection was committed before the outcome was knowable. Every loot drop, gacha pull, and randomized selection — independently verifiable, trustlessly.
Try It Now
npx @fairseal/commit
One command. A verifiable gacha pull in your terminal. No setup.
Quick Start
npm install @fairseal/commit
import { createCommitment, resolveCommitment, createReceipt, verifyReceipt } from '@fairseal/commit';
// 1. Lock your loot table BEFORE the outcome is knowable
const commitment = createCommitment({
rule: JSON.stringify(LOOT_TABLE),
inputs: [playerId, pullNumber.toString()],
revealAfter: 10,
});
// 2. Resolve with verifiable entropy from drand
const resolution = await resolveCommitment(commitment);
// 3. Your algorithm + verifiable entropy = provably fair drop
const drop = yourWeightedPull(LOOT_TABLE, resolution.beaconRandomness);
// 4. Package as a receipt anyone can verify
const receipt = createReceipt(commitment, resolution);
const proof = await verifyReceipt(receipt); // ✅ PARTIAL
How It Works
- Commit — Lock your drop table + player ID into a hash before the randomness exists
- Entropy — Wait for a public drand beacon round (Cloudflare + Protocol Labs)
- Resolve — Derive the selection from beacon entropy + your committed rule
- Verify — Anyone can re-run every step. drand beacon signatures are BLS12-381-verified; FairSeal receipt signatures use EIP-191 (secp256k1) / Ed25519 — receipts are never BLS-signed. No trust required.
Performance
| Operation | Time |
|---|---|
| Commitment creation | 0.006ms (170,000+/sec) |
| Beacon fetch | ~200ms |
| drand beacon verification (BLS12-381) | ~150ms |
| Receipt size | 0.9 KB |
Client-side. No server. No account. No fees for PARTIAL verification.
Packages
| Package | Description |
|---|---|
@fairseal/game | Game API for RGS studios. Slots, gacha, loot boxes. (v0.1 ALPHA) |
@fairseal/commit | Committed selection receipts. Core library. |
@fairseal/core | Cryptographic primitives, signing, Merkle trees. |
@fairseal/verify | Independent receipt verification. |
@fairseal/mcp-server | MCP server for AI agents. Verifiable entropy, provably-fair games, cryptographic receipt verification via Model Context Protocol. |
Use Cases
| Scenario | How |
|---|---|
| Gacha / loot box | Every pull has a receipt. Players verify drops match published rates. |
| Boss loot drops | Drop table committed per encounter. No ninja-nerfing. |
| Matchmaking | Pairing algorithm committed. Players verify no favoritism. |
| Tournament brackets | Seeding provably random, not rigged. |
| NFT mint order | Queue provably fair — no insider front-running. |
| Slot machines | Seed Commitment Model — verifiable spins, no nonce chain. |
Result Notarization vs. Activity Receipts
Most "agent receipts" today are activity receipts: the platform logs what an agent did, and you trust whoever wrote the log. Fairseal receipts are result notarization — a different trust model:
| Activity receipts (platform logs) | Fairseal result notarization | |
|---|---|---|
| Who do you trust? | The operator writing the log | No one — receipts verify offline |
| What is proven? | That an action was recorded | That a result was committed before the outcome was knowable |
| Time proof | Server timestamp (operator-controlled) | External anchor on Base (independently checkable) |
| Tamper evidence | Depends on log integrity | Hash-anchored; any modification breaks verification |
Related standards: payment-authorization protocols like Google/Mastercard AP2 (mandates), Visa TAP, and OpenAI/Stripe ACP prove that an agent may act and who it is. Fairseal proves what happened — that a result was committed and hasn't been altered since. Fairseal settles micropayments over Coinbase's x402 and does not implement AP2/TAP/ACP; the layers are complementary.
Links
- 🌐 fairseal.io — Landing page
- 📦 npm @fairseal — All packages
- 🔍 verify.fairseal.io — Receipt verifier
- 📖 @fairseal/commit README — Full documentation
Listings
- PayAPI Market — FairSeal Cryptographic Receipts API — verified listing (settled on-chain test payment)
License
MIT — Fairseal
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.