
Insumer
com.insumermodelv1.14.1Updated Oct 2, 2026
Read-first blockchain verification. ECDSA-signed booleans across 37 chains. 27 tools.
Overview
Lets an assistant check on-chain wallet conditions across 37 chains and return signed true/false attestations, trust profiles, and merchant discount codes.
- What it does
- Wraps the InsumerAPI condition-based access service in 27 tools. The main ones verify on-chain conditions such as token balances, NFT ownership, EAS attestations, and Farcaster identity, returning an ECDSA-signed boolean with a condition hash and block reference rather than balances or amounts. It also generates wallet trust profiles (up to 166 presence checks across 29 chains), batch trust profiles for up to 10 wallets, signed discount codes, and merchant directory lookups. Results can be returned as a JWT for middleware that accepts bearer tokens.
- When to use it
- Use it when an assistant needs to gate access or make decisions on verified on-chain facts, for example checking that a wallet holds a threshold of a token or an NFT before granting something. Also useful for wallet trust scoring, merchant discount eligibility, and commerce protocol flows where a signed, offline-checkable result matters.
- Requirements
- Runs locally over stdio, typically via npx mcp-server-insumer, so Node.js is needed. Requires either INSUMER_API_KEY (an insr_live_ key, obtainable free with an email) or INSUMER_PAYMENT_KEY for pay-per-call mode. Network access to the InsumerAPI service and blockchain data sources is required. Desktop-only; no web executable.
Installation
In SourceWeft
- Open Insumer in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
mcp-server-insumer
MCP server for InsumerAPI: condition-based access infrastructure. Send a wallet and conditions, get a signed boolean across 37 chains. No balances exposed, no identity required. Every result is signed and checkable offline against the published keys, and on EVM chains an optional Merkle proof lets the verifier check the balance against the block header without trusting the API.
Enables AI agents (Claude Desktop, Cursor, Windsurf, and any MCP-compatible client) to add condition-based access to any workflow — verify on-chain conditions, discover merchants, generate signed discount codes, and onboard new merchants.
In production: AsterPay — a regulated payments stack — runs live ERC-8183 agentic-commerce trust scoring on InsumerAPI. Case study.
Also available as: LangChain (26 tools, PyPI) | ElizaOS (10 actions, npm) | OpenAI GPT (GPT Store) | insumer-verify (client-side verification, npm)
Full AI Agent Verification API guide: covers all 37 chains, trust profiles, commerce protocols, and signature verification.
Quick Start
Claude Desktop
Add to your claude_desktop_config.json:
Cursor / Windsurf
Add to your MCP settings:
Get a key — no signup, no dashboard, no password
Three paths, all give you a working insr_live_... key in seconds with 100 reads/day and 10 verification credits. One free key per email.
Option A — Let your agent do it: Start the server without a key. Your AI agent can call the insumer_setup tool with your email to generate a free key instantly. Add it to your config and restart.
Option B — Terminal:
Option C — Browser: Enter your email on insumermodel.com — the key appears inline.
Set it as INSUMER_API_KEY in your config.
Already have a key? Manage usage, top up, or upgrade at insumermodel.com/developers/account/.
Option D — Pay per call with x402 (no key at all)
Instead of a key, set INSUMER_PAYMENT_KEY to a throwaway Base wallet funded with a few dollars of USDC. Metered calls (insumer_attest, insumer_wallet_trust, insumer_batch_wallet_trust) are then paid inline via x402 — the server requests a price, signs an EIP-3009 USDC authorization on Base, and retries. No signup, no credits, no dashboard.
- Base USDC only; the wallet needs USDC but no ETH (settlement is gasless).
- Each call spends a few cents (attest $0.05, trust $0.15). Use a dedicated throwaway wallet funded with a small amount — never a wallet holding meaningful funds.
- Every quote is checked before the wallet signs. The server pays only InsumerAPI's own receiving address (
0xAd982CB19aCCa2923Df8F687C0614a7700255a23), only in USDC on Base, and never more than the cap: $3.00 per call by default, the price of the largest call today (a 10-wallet trust batch with Merkle proofs). Anything else is refused and nothing is signed. SetINSUMER_MAX_PAYMENT_USDCto change the cap, e.g."0.25"if you only attest. The cheapest call is $0.05, so a cap below that refuses every paid call (the server warns at startup). A malformed value turns pay-per-call off rather than falling back to the default. - If both
INSUMER_API_KEYandINSUMER_PAYMENT_KEYare set, the key (credits) is used.
What You Get Back
When your agent calls insumer_attest, you get an ECDSA-signed attestation:
The sig is an ECDSA P-256 signature (base64, P1363 r||s, 88 characters). The kid identifies the key and selects the signed bytes: insumer-attest-v2 signs "insumer.attestation.v2\n" + canonical_json({v: 2, id, pass, results, attestedAt}) (keys sorted at every level); insumer-attest-v1 signs the bare JSON.stringify of {id, pass, results, attestedAt} in insertion order. Since 2026-09-01 every attest and trust response also carries a post-quantum companion, pqSig and pqKid (ML-DSA-65 over the post-quantum domain tag plus the same classical preimage the kid selects), added beside sig and kid without changing them. The conditionHash is a SHA-256 of the exact condition logic that was evaluated.
No balances. No amounts. Just a cryptographically signed true/false.
For XRPL conditions, results include ledgerIndex, ledgerHash (validated ledger hash), and trustLineState: { frozen: boolean } instead of blockNumber/blockTimestamp. Native XRP conditions include ledgerIndex and ledgerHash but not trustLineState. Frozen trust lines cause met: false.
Wallet Auth (JWT)
Add format: "jwt" to the insumer_attest tool parameters to receive the attestation as a standard JWT bearer token:
The response includes an additional jwt field containing an ES256-signed JWT, and beside it a pqJwt sibling (a compact JWS with alg ML-DSA-65 carrying the same claims, signed under insumer-attest-pq1). The jwt token is verifiable by any standard JWT library via the JWKS endpoint at GET /v1/jwks — making it compatible with Kong, Nginx, Cloudflare Access, AWS API Gateway, and other middleware that accepts JWT bearer tokens.
Verify the Response
Your agent gets the attestation. Your application should verify it. Install insumer-verify (also on PyPI for Python: pip install insumer-verify, same checks, same 27 published test vectors):
This reports five independent verdicts: ECDSA signature, condition hash integrity, block freshness, attestation expiry, and the post-quantum companion (insumer-verify 1.8.1+ reports it as verified, refuted, absent, or unverifiable). Zero runtime dependencies, uses Web Crypto API.
Tools (27)
Setup (free, no auth)
Key Discovery (free)
On-Chain Verification (cost credits)
token_balancethresholds are decimal strings. Passthresholdas"100", not100. Keys created from 2026-06-10 sign withkid: insumer-attest-v2, which preserves full precision and rejects a JSON number with a400. Theinsumer_attesttool accepts a number or string and coerces to the canonical string; olderinsumer-attest-v1keys accept either.
Discovery (free)
Credits & Keys
Merchant Onboarding (owner-only)
Domain Verification (owner-only)
Commerce Protocol Integration
Pricing
Tiers: Free (100 reads/day, 10 credits) | Pro $29/mo (1,000 credits/mo, 10,000/day) | Enterprise $99/mo (5,000 credits/mo, 100,000/day)
Volume discounts: $5–$99 = $0.04/call (25 credits/$1) · $100–$499 = $0.03 (33/$1, 25% off) · $500+ = $0.02 (50/$1, 50% off)
Platform wallets:
- EVM (USDC/USDT):
0xAd982CB19aCCa2923Df8F687C0614a7700255a23 - Solana (USDC/USDT):
6a1mLjefhvSJX1sEX8PTnionbE9DqoYjU6F6bNkT4Ydr - Bitcoin:
bc1qg7qnerdhlmdn899zemtez5tcx2a2snc0dt9dt0 - Tron (USDT-TRC20):
TC5yvwkAMakkXtUxYiu2Yn1xbBcwYuD6cn
Supported payment chains: Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, Solana, Bitcoin, Tron. Tokens sent on unsupported chains cannot be recovered. All purchases are final and non-refundable. Full pricing →
Handling rpc_failure Errors
If the API cannot reach one or more blockchain data sources after retries, endpoints that produce signed attestations (insumer_attest, insumer_wallet_trust, insumer_batch_wallet_trust) return ok: false with error code rpc_failure. No signature, no JWT, no credits charged. This is a retryable error — the MCP client should retry after a short delay (2-5 seconds).
Important: rpc_failure is NOT a verification failure. Do not treat it as pass: false. It means the data source was temporarily unavailable and the API refused to sign an unverified result.
Supported Chains (37)
31 EVM chains + Solana + XRP Ledger + Bitcoin + Tron + Stellar + Sui. Includes Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, XDC, Robinhood Chain, Arc, and 21 more EVM. Full list →
Also Available As
- Claude Code Skill:
smithery skill add douglasborthwick/insumer-skill(Smithery · GitHub) — for writing wallet auth into your own projects from inside Claude Code. This MCP server gives an agent runtime access to the API; insumer-skill helps developers author integration code at build time. Different surfaces, same primitive. - ElizaOS Plugin:
@insumermodel/plugin-eliza(npm) - LangChain (Python):
pip install langchain-insumer(PyPI) - OpenAI GPT: InsumerAPI Wallet Auth (GPT Store)
- Verifier (offline JWKS):
npm install insumer-verify(npm, source)
Development
License
MIT
Source: README.md at commit 2676e86
Tools
0Version history
1- v1.14.1LatestOct 2, 2026


