Insumer

mcp-server-insumer

[npm] [License: MIT] [Glama] [License: MIT]

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 non-custodial payments orchestrator settling through licensed EU partners, uses InsumerAPI attestations in its live ERC-8183 agentic-commerce trust checks. 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:

{  "mcpServers": {    "insumer": {      "command": "npx",      "args": ["-y", "mcp-server-insumer"],      "env": {        "INSUMER_API_KEY": "insr_live_..."      }    }  }}

Cursor / Windsurf

Add to your MCP settings:

{  "insumer": {    "command": "npx",    "args": ["-y", "mcp-server-insumer"],    "env": {      "INSUMER_API_KEY": "insr_live_..."    }  }}

Get a key: just an email, no dashboard, no password

Three paths, all give you a working insr_live_... key in seconds with 10 free verifications plus 100 requests a day. 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.

curl -s -X POST https://api.insumermodel.com/v1/keys/create \  -H "Content-Type: application/json" \  -d '{"email": "[email protected]", "appName": "MCP Server", "tier": "free"}'

Option C: browser. Enter your email on insumermodel.com and 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.

{  "mcpServers": {    "insumer": {      "command": "npx",      "args": ["-y", "mcp-server-insumer"],      "env": { "INSUMER_PAYMENT_KEY": "0x<throwaway-wallet-private-key>" }    }  }}

• 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 (0xee432065474D2C852700f74e3fD81e2Bcc16a3D4, or the address it quoted before 2026-10-19, 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. Set INSUMER_MAX_PAYMENT_USDC to 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_KEY and INSUMER_PAYMENT_KEY are set, the key (credits) is used.

Hosted endpoint (no install)

The same server runs at https://api.insumermodel.com/mcp over MCP streamable HTTP, for clients that connect by URL: ChatGPT plugins and developer-mode connectors, claude.ai custom connectors, and hosted agent platforms that cannot run an npm package. Paste the URL; there is nothing to configure.

It is shared and anonymous, so it serves the ten tools that make sense without a caller identity (HOSTED_TOOLS: signing keys, attest, compliance templates, wallet trust and batch trust, the merchant and token directories, the free discount check, code validation), and the metered tools share one free daily allowance. Past it, a call is refused with a pointer here. For your own allowance, key and credit management, or the merchant tools, run the package locally with your key as above.

To host the server yourself, build it and run node build/http.js with INSUMER_API_KEY set (PORT, INSUMER_HOSTED_TOOLS and INSUMER_DAILY_CAP are optional), or embed it: createInsumerServer(options) from the package root returns a configured server for any transport.

What You Get Back

When your agent calls insumer_attest, you get an ECDSA-signed attestation:

{  "ok": true,  "data": {    "attestation": {      "id": "ATST-A7C3E1B2D4F56789",      "pass": true,      "results": [        {          "condition": 0,          "met": true,          "label": "USDC >= 1000 on Ethereum",          "type": "token_balance",          "chainId": 1,          "evaluatedCondition": {            "chainId": 1,            "contractAddress": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",            "operator": "gte",            "threshold": "1000",            "type": "token_balance"          },          "conditionHash": "0x8a3b...",          "blockNumber": "0x1799043",          "blockTimestamp": "2026-03-26T20:04:23.000Z"        }      ],      "passCount": 1,      "failCount": 0,      "attestedAt": "2026-02-28T12:34:57.000Z",      "expiresAt": "2026-02-28T13:04:57.000Z"    },    "sig": "NgA7BO8SAildiTrgIQY2UyXsBrySZknkP85pT2Zqv8Hq0KsCsB8DRFVMkXgnXtCXrbb726Is6k4LyyBYU+f/Pw==",    "kid": "insumer-attest-v2",    "pqSig": "<base64 ML-DSA-65 signature>",    "pqKid": "insumer-attest-pq1"  },  "meta": {    "version": "1.0",    "timestamp": "2026-02-28T12:34:57.000Z",    "creditsRemaining": 99,    "creditsCharged": 1  }}

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. Every attest and trust response is signed twice: ES256 and a post-quantum ML-DSA-65 signature, pqSig and pqKid (over the post-quantum domain tag plus the same classical preimage the kid selects; pqJwt beside jwt), 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:

{  "wallet": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",  "conditions": [ ... ],  "format": "jwt"}

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, which makes 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):

npm install insumer-verify

import { verifyAttestation } from "insumer-verify";
// attestationResponse = the full API envelope {ok, data: {attestation, sig, kid, pqSig, pqKid}, meta}// Do NOT pass attestationResponse.data; the function expects the outer envelopeconst result = await verifyAttestation(attestationResponse, {  jwksUrl: "https://insumermodel.com/.well-known/jwks.json",  maxAge: 120, // reject if block data is older than 2 minutes});
if (result.valid) {  // Signature verified, condition hashes match, not expired  const pass = attestationResponse.data.attestation.pass;  console.log(`Attestation ${pass ? "passed" : "failed"} all conditions`);} else {  console.log("Verification failed:", result.checks);}

This reports five independent verdicts: ECDSA signature, condition hash integrity, block freshness, attestation expiry, and the post-quantum signature (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_balance thresholds are decimal strings. Pass threshold as "100", not 100. Keys created from 2026-06-10 sign with kid: insumer-attest-v2, which preserves full precision and rejects a JSON number with a 400. The insumer_attest tool accepts a number or string and coerces to the canonical string; older insumer-attest-v1 keys accept either.

Discovery (free)

Credits & Keys

Merchant Onboarding (owner-only)

Domain Verification (owner-only)

Commerce Protocol Integration

Pricing

Tiers: Free (10 free verifications plus 100 requests a day) | 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)

Key and credit purchases are paid in USDC only. Receiving addresses:

• USDC on Ethereum, Base, Polygon, Arbitrum, Optimism or Avalanche: 0xee432065474D2C852700f74e3fD81e2Bcc16a3D4
• USDC on BNB Chain: 0xAd982CB19aCCa2923Df8F687C0614a7700255a23 (USDC sent to it on the other EVM chains is also accepted during the changeover)
• USDC on Solana: 8fyEGM5tRjMocKQWaVXyM2XvvnTxR3sWdrYtug2zeLX4 (USDC sent to 6a1mLjefhvSJX1sEX8PTnionbE9DqoYjU6F6bNkT4Ydr is also accepted during the changeover)

Supported payment chains: Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, Solana. USDT and other tokens are refused and not credited; tokens sent on unsupported chains cannot be recovered. All purchases are final and non-refundable. Full pricing →

Sender signature. A purchase that binds a key to a wallet (every key purchase, a credit purchase on a key with no registered wallet, or updateWallet: true from a different wallet) takes senderSignature: the wallet that sent the payment signs this exact text, five lines joined by \n with no trailing newline:

api.insumermodel.comConfirm the wallet that sent this payment.Purpose: key purchaseChain: eip155:8453Transaction: 0x<transaction hash, lowercase hex>

Purpose is credit purchase for a credit purchase; Chain is eip155:<chainId> on an EVM chain or solana (with the Solana signature as given). Call once without senderSignature and the 400 returns the exact text. EVM wallets sign with personal_sign (EIP-191, 0x hex; smart wallets are checked with ERC-1271); Solana wallets sign with signMessage (ed25519, base58 or base64). A 403 means the signature is not from the wallet that sent the payment; a 503 means a smart-wallet check could not complete and the payment was not used.

Handling rpc_failure Errors

If the API cannot reach one or more blockchain data sources after retries, insumer_attest, insumer_wallet_trust, insumer_verify, insumer_acp_discount, insumer_ucp_discount and insumer_check_discount return ok: false with error code rpc_failure. No signature, no JWT, no credits charged. insumer_batch_wallet_trust answers normally and carries an error entry for any wallet whose reads did not complete, beside the wallets that were signed. 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: git clone https://github.com/insumerapi/insumer-skill.git ~/.claude/skills/insumer (GitHub · Smithery), 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

npm installnpm run build
# Test with MCP Inspectornpx @modelcontextprotocol/inspector node build/index.js

License

MIT