A
licenseA
qualityF
maintenanceAn MCP server that empowers AI agents to inspect any wallet’s balance and onchain activity across major EVM chains and Solana chain.
3
9
MIT
InsumerAPI
by insumerapi
This MCP server gives AI agents runtime access to InsumerAPI's condition-based access infrastructure: signed, balance-free yes/no answers about wallets across 37 chains, plus wallet trust profiles, merchant discount tooling, and key/credit management.
Verify on-chain conditions (
insumer_attest): check 1–10 conditions per wallet — token balances, NFT ownership, EAS attestations, Farcaster ID, arbitrary view calls, ratio-to-amount/supply, ERC-8004 agent registration, ERC-7710 delegations — returning an ECDSA + ML-DSA-65 signed boolean with condition hashes and block/ledger anchors, optionally with EIP-1186 Merkle proofs or a Wallet Auth JWT.Score wallet trust (
insumer_wallet_trust,insumer_batch_wallet_trust): generate signed trust fact profiles across 145–166 presence checks in up to 13 dimensions, single or batched (up to 10 wallets) with partial success.Fetch signing keys (
insumer_jwks): get the JWKS (ECDSA P-256 + post-quantum ML-DSA-65 AKP entries) to verify responses offline.Discover merchants and tokens (
insumer_list_merchants,insumer_get_merchant,insumer_list_tokens): browse the public directory, profiles, accepted tokens, and wallet terms.Check and issue discounts (
insumer_check_discount,insumer_verify,insumer_acp_discount,insumer_ucp_discount,insumer_validate_code): calculate eligibility, create signed INSR codes, and return discounts in OpenAI/Stripe ACP or Google UCP checkout formats; validate codes for merchant backends.Onboard and manage merchants (
insumer_create_merchant,insumer_merchant_status,insumer_configure_tokens,insumer_configure_nfts,insumer_configure_settings,insumer_publish_directory): create stores, set token/NFT tiers, discount modes, caps, and publish to the directory.Verify merchant domains (
insumer_request_domain_verification,insumer_verify_domain): place a DNS TXT, meta tag, or file token to earn a trust badge.Manage keys, credits, and payments (
insumer_setup,insumer_credits,insumer_buy_key,insumer_buy_credits,insumer_buy_merchant_credits,insumer_confirm_payment): generate a free key from an email, check balances, and register USDC/USDT/BTC/USDT-TRC20 payments sent on-chain.List compliance templates (
insumer_compliance_templates): get preconfigured EAS schema/attester setups such as Coinbase Verifications and Gitcoin Passport.
Supports on-chain verification of token balances and NFT ownership on the BNB Chain.
Enables verification of Coinbase Verifications and integration with the Coinbase ecosystem for agent wallet trust scoring.
Provides on-chain verification for token balances, NFT ownership, and other conditions on the Ethereum blockchain.
Allows verification of Farcaster identities and associated on-chain data.
Integrates with Google UCP (Universal Commerce Protocol) for discount eligibility and commerce applications.
Supports checking discount eligibility using the OpenAI ACP commerce protocol format.
Enables on-chain verification and access to compliance templates like Gitcoin Passport on the Optimism network.
Provides tools for verifying token balances and NFT ownership on the Polygon network.
Enables on-chain verification for token balances and wallet trust profiles on the Solana blockchain.
Supports checking discount eligibility using the Stripe ACP commerce protocol format.
Provides on-chain verification for native XRP, trust line tokens, and NFTs on the XRP Ledger (XRPL).
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 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: no signup, 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": "you@example.com", "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 (
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.
Related MCP server: MolTrust
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-verifyimport { 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 envelope
const 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)
Tool | Description |
| Generate a free API key instantly. Takes an email, returns an |
Key Discovery (free)
Tool | Description |
| Get the JWKS: five entries over two keys. The ECDSA P-256 key under |
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.
Tool | Description |
| Verify on-chain conditions (token balances, NFT ownership, EAS attestations, Farcaster identity, |
| List available EAS compliance templates (Coinbase Verifications on Base, Gitcoin Passport on Optimism). Free. |
| Generate ECDSA-signed wallet trust fact profile. 155 base checks across 27 chains in 10 dimensions (stablecoins, governance, NFTs, staking, institutional stablecoins, tokenized treasuries, stablecoin deposits, wrapped bitcoin, names, account), up to 176 checks across 29 chains in 14 dimensions with optional Solana, XRPL, Bitcoin, and Tron wallets (Stellar and Sui wallets switch on rows inside the base dimensions). Every check is a presence check; the account dimension's two rows per chain (contract code, EIP-7702 delegation, on Ethereum, Base, Arbitrum, Optimism and Polygon) are present or not present. Dimensions arrive in a fixed order: the base dimensions as listed, then any of solana, xrpl, bitcoin and tron that were switched on. The signed |
| Batch trust profiles for up to 10 wallets. Each wallet object supports optional |
| Create signed discount code (INSR-XXXXX, 30-min expiry) for a wallet at a merchant. A code that carries a discount costs 1 credit from the API key that owns the store; a 0% result is free. A caller using another key is not charged. Optional |
Discovery (free)
Tool | Description |
| Browse the merchant directory. Filter by token, verification status. |
| Get full public merchant profile. |
| List the tokens and NFTs listed in the Insumer registry. Filter by chain, symbol, type. A directory, not the list of what can be checked: an attestation checks any token on a supported chain, and NFTs on EVM chains, Solana and XRPL. |
| Calculate discount for a wallet at a merchant. |
Credits & Keys
Tool | Description |
| Buy a new API key with USDC, USDT, BTC, or USDT-TRC20 (no auth required). Agent-friendly: no email needed, sender wallet becomes the key's identity. One key per wallet. Volume discounts: $0.04–$0.02/call. Supported chains: Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, Solana, Bitcoin, Tron. Non-refundable. |
| Check credit balance and tier. |
| Buy verification credits with USDC, USDT, BTC, or USDT-TRC20. Volume discounts: $0.04–$0.02/call. Supported chains: Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, Solana, Bitcoin, Tron. Non-refundable. First purchase registers sender wallet; subsequent purchases must match or include |
| Confirm USDC payment for a discount code. |
Merchant Onboarding (owner-only)
Tool | Description |
| Create new merchant, owned by the key that creates it. No balance of its own: that key pays for its codes, scans and taps. |
| Get full private merchant details. |
| Set token discount tiers. Tier discounts are whole numbers from 1 to 50. Tokens can carry a display |
| Set NFT collections: a whole-number discount from 1 to 50, or |
| Set discount mode, cap, the terms for wallets without proof of control, USDC payments. |
| Publish merchant to public directory. |
| Kept for compatibility. A store has no balance of its own: a USDC, USDT, BTC, or USDT-TRC20 payment submitted here adds regular credits to the API key that owns the store, at a flat 25 credits per $1 ( |
Domain Verification (owner-only)
Tool | Description |
| Request a verification token for a merchant's domain. Returns token and 3 methods (DNS TXT, meta tag, file upload). |
| Complete domain verification after placing the token. Verified merchants get a trust badge. |
Commerce Protocol Integration
Tool | Description |
| Check discount eligibility in OpenAI/Stripe ACP format. Returns coupon objects and per-item allocations. A code that carries a discount costs the store's owner key 1 credit; a 0% result is free. A caller using another key is not charged. |
| Check discount eligibility in Google UCP format. Returns title, extension field, and applied array. A code that carries a discount costs the store's owner key 1 credit; a 0% result is free. A caller using another key is not charged. |
| Validate an INSR-XXXXX discount code. Returns validity, discount percent, expiry. Free, no auth. |
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)
Platform wallets:
EVM (USDC/USDT):
0xAd982CB19aCCa2923Df8F687C0614a7700255a23Solana (USDC/USDT):
6a1mLjefhvSJX1sEX8PTnionbE9DqoYjU6F6bNkT4YdrBitcoin:
bc1qg7qnerdhlmdn899zemtez5tcx2a2snc0dt9dt0Tron (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, 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 install
npm run build
# Test with MCP Inspector
npx @modelcontextprotocol/inspector node build/index.jsLicense
MIT
Available Tools
27 toolsinsumer_acp_discountDiscount in ACP formatInspect
Check token-holder discount eligibility in OpenAI/Stripe Agentic Commerce Protocol (ACP) format. Returns coupon objects, applied/rejected arrays, and per-item allocations compatible with ACP checkout flows. The on-chain check is the same one behind INSR discount codes, wrapped in ACP format. A code that carries a discount costs one credit from the API key that owns the store; a 0% result is free. A caller using another key is not charged, and stores on a licensed platform are covered by its license. Paid discount codes requested with a key other than the store's owner are subject to an hourly limit (429; the message says when to try again). Takes an EVM, Solana or XRPL wallet. An rpc_failure error (503) means a read did not complete and nothing was signed: retry, and never treat it as a no. Optional walletProof proves you control the EVM wallet: the response then says walletProven true, and the full discount its holdings earn applies, without the store's daily limit for unproven wallets. Without it the store's terms for unproven wallets apply, and discountIfProven shows what a proof would get.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | Optional line items for per-item cent-amount allocations | |
| wallet | No | EVM wallet address (0x...) | |
| merchantId | Yes | Merchant ID | |
| xrplWallet | No | XRPL wallet address (r-address) | |
| walletProof | No | Optional proof that you control 'wallet' (EVM only; send it without solanaWallet or xrplWallet). Sign this EIP-4361 message with the wallet, within 5 minutes, with a nonce you never reused: api.insumermodel.com wants you to sign in with your Ethereum account: <wallet> Prove wallet for a discount. URI: https://api.insumermodel.com/v1/merchants/<merchantId> Version: 1 Chain ID: 1 Nonce: <8+ random letters or digits> Issued At: <ISO 8601 time now> A proven wallet gets the full discount its holdings earn (under the store's tiers and cap), without the daily limit for unproven wallets. Without it, the store's terms for unproven wallets apply (see walletTerms on the merchant). A proof that fails returns 401 and uses no credit. Smart-contract wallets are not accepted yet. | |
| solanaWallet | No | Solana wallet address (base58) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
insumer_attestVerify wallet conditions (signed)Inspect
Evaluate a list of 1 to 10 conditions against a wallet's on-chain state and return one signed attestation: a yes or no for each condition, never the balance. One call reads the chain for every condition in the list and returns a single attestation covering all of them, so conditions of different kinds and on different chains are combined in one signed result. A condition states what must be true of the wallet, such as a minimum token balance, ownership of an NFT, an attestation held or a registered agent ID; the type field on each condition lists the kinds available and the fields each one takes. Chains: EVM chains plus Solana, XRPL, Bitcoin, Tron, Stellar and Sui; Bitcoin, Tron, Stellar and Sui support token_balance only. The attestation is signed twice: ES256, with a kid identifying the key, and a post-quantum ML-DSA-65 signature (pqSig, pqKid). Each result includes evaluatedCondition, a SHA-256 conditionHash, and the block (EVM), ledger (XRPL, Stellar) or checkpoint (Sui) it was read at. An attestation expires 30 minutes after it is signed, or 5 minutes when it includes a delegation condition. Costs 1 credit (2 with proof: 'merkle'). An rpc_failure error (503) means a read did not complete and nothing was signed: retry, and never treat it as a no. Current chain and check counts: https://insumermodel.com/llms.txt
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| proof | No | Set to 'merkle' for EIP-1186 Merkle proofs (2 credits, refunded to 1 when no proof is delivered). For token_balance or ratio_to_amount against an ERC-20, a storage proof of the balance slot (no subject field); for the same conditions with contractAddress 'native', an account proof whose balance field is the value evaluated (subject 'account_balance'); for account_code, an account proof whose codeHash is the value evaluated (subject 'account_code'); for erc7710_delegation, a storage proof of the revocation slot (subject 'delegation_revocation') on managers with an on-chain-verified layout. Supported EVM chains only (not ZKsync Era, Sei, Viction or XDC Network, and not on non-EVM chains). | |
| format | No | Set to 'jwt' to include a Wallet Auth by InsumerAPI token (ES256-signed JWT) in the response, with its ML-DSA-65 sibling pqJwt beside it. The jwt is verifiable by any standard JWT library using JWKS at /.well-known/jwks.json. | |
| wallet | No | EVM wallet address (0x...) | |
| suiWallet | No | Sui wallet address (0x + 64 hex chars). For verifying SUI or other Sui coins (e.g. USDC). Use chainId 'sui' with the Sui coin type as contractAddress: '0x2::sui::SUI' for native SUI, or the full coin type address::module::Name for other coins. The string 'native' is not accepted on Sui. | |
| conditions | Yes | The list of 1 to 10 conditions to evaluate. All of them are read in this one call and covered by the one signed attestation. | |
| tronWallet | No | Tron wallet address (T-prefixed, base58). For verifying TRX or TRC20 tokens (USDT-TRC20). Use chainId 'tron'. | |
| xrplWallet | No | XRPL wallet address (r-address). For verifying XRP, trust line tokens (RLUSD, USDC), or NFTs on XRP Ledger. | |
| solanaWallet | No | Solana wallet address (base58) | |
| bitcoinWallet | No | Bitcoin address (P2PKH, P2SH, bech32, or Taproot). For verifying native BTC balance. Use chainId 'bitcoin' with contractAddress 'native'. | |
| stellarWallet | No | Stellar wallet address (G-prefixed). For verifying XLM or trustline assets (USDC, BENJI, etc.). Use chainId 'stellar' with the asset issuer's G-address as contractAddress and pass assetCode (e.g. 'USDC'). Soroban contract balances not visible; classic trustlines only. | |
| declaredLimits | No | Set to 'omit' to leave decoded caveat limits out of the signed results of erc7710_delegation conditions, so a forwarded attestation does not carry the principal's spending ceiling. met, delegationHash, and conditionHash are byte-identical either way. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
insumer_batch_wallet_trustBatch wallet trust profiles (signed)AInspect
Generate wallet trust fact profiles for up to 10 wallets in a single request. Faster than sequential calls. Each wallet gets an independently signed profile with its own TRST-XXXXX ID: 155 base checks across 27 chains in 10 dimensions (stablecoins, governance, nfts, staking, institutional_stablecoins, tokenized_treasuries, stablecoin_deposits, wrapped_bitcoin, names, account), up to 176 checks across 29 chains in 14 dimensions with the optional Solana, XRPL, Bitcoin and Tron wallets; the signed conditionSetVersion (currently 2026-10-08) names the check list. Dimensions arrive in a fixed order, identical for every wallet in the batch: the base dimensions as listed, then any of solana, xrpl, bitcoin and tron that were switched on, in that order. Supports partial success: failed wallets get error entries while successful ones return full profiles. Costs 3 credits per successful wallet (6 with proof: 'merkle'); credits are charged only for successful profiles, while a pay-per-call (x402) payment covers every wallet in the request. A wallet whose reads did not complete gets an error entry and no signed profile: retry that wallet, and never treat the entry as a no. Each profile lists every check, so the response is large; by default the text is a summary per wallet (profile ID, held / not held / not evaluated counts, and the checks held in each dimension, in the fixed dimension order; the account dimension's checks are present rather than held), and the complete signed profiles are returned unchanged as structuredContent. Set detail to 'full' on the call to get the complete signed profiles as text too. Profiles cannot be fetched again, so a later call signs fresh profiles and is charged again.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| proof | No | Set to 'merkle' for EIP-1186 Merkle storage proofs on all wallets (6 credits/wallet). | |
| detail | No | 'summary' (default): the text is a short summary per wallet and the complete signed profiles are in structuredContent. 'full': the complete signed profiles as text too, tens of thousands of characters per wallet (more with optional wallets or merkle proofs). Choose it on the call that needs it: profiles cannot be fetched again, so a second call signs fresh profiles and is charged again. Not sent to the API; it does not change the price of the call. | |
| wallets | Yes | 1-10 wallet entries to profile |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses partial-success semantics (error entries vs full profiles), exact pricing (3 credits/successful wallet, 6 with merkle, x402 covers all wallets), the warning never to treat an errored wallet as a 'no', and the no-caching/irreversibility constraint. These go well beyond the annotations and align with idempotentHint=false and readOnlyHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose and batch benefit, then cost and output behavior; every sentence carries operational information. It is a single dense paragraph and the dimension enumeration is long, but little is truly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an existing output schema plus a highly detailed input schema, the description still covers the pieces an agent must know: cost per call, partial failure handling, detail-mode tradeoff, dimension order, and non-refetchability. Nothing material is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: fixed dimension ordering per batch, which optional wallets add dimensions vs. merely enabling evaluation, and the credit effect of proof='merkle'. That extra context raises it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Generate), resource (wallet trust fact profiles), and scope (up to 10 wallets in a single request), with an explicit speed rationale versus sequential calls. This clearly separates it from the single-wallet sibling insumer_wallet_trust.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use guidance: use detail='full' on the call that needs the full text, retry only the failed wallet on partial success, and note that a later call signs fresh profiles and charges again. It does not explicitly name the single-wallet alternative, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_buy_creditsAdd credits from a paymentADestructiveInspect
Add verification credits to the current API key against a USDC, USDT, BTC, or USDT-TRC20 payment the caller has already sent. This tool does not move funds: it submits the transaction hash. USDC/USDT on EVM and Solana (auto-detected), USDT-TRC20 on Tron, BTC on Bitcoin (converted at market rate, 1 confirmation required). Crypto sent on unsupported chains cannot be recovered. Non-refundable. The first purchase registers the sender wallet to the API key; later purchases must come from the same sender, and updateWallet: true replaces the registered wallet. Current prices and volume discounts: https://insumermodel.com/pricing/
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Stablecoin amount sent (minimum 5). Not required for BTC. | |
| txHash | Yes | Transaction hash proving payment | |
| chainId | Yes | Payment chain: 1, 8453, 137, 42161, 10, 56, 43114, 'solana', 'bitcoin', or 'tron'. EVM/Solana accept USDC and USDT (auto-detected). Bitcoin accepts BTC (converted to USD at market rate). Tron accepts USDT-TRC20. | |
| updateWallet | No | Set true to replace the registered sender wallet with this transaction's sender |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (destructiveHint, idempotentHint=false, openWorldHint), but the description adds substantial context beyond them: it does not move funds, unsupported chains are unrecoverable, purchases are non-refundable, the first purchase registers the sender wallet, later purchases must use the same sender, and updateWallet replaces it. These are material behaviors an agent cannot derive from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded, and every clause carries non-obvious information (chain support, conversion, wallet rules, irreversibility). It is on the longer side for a description, but no sentence is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and the description covers the mechanics, supported chains, irreversibility, wallet registration, and a pricing pointer. An agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the schema documents amount, txHash, chainId, and updateWallet. The description still adds useful meaning beyond it: EVM/Solana auto-detect USDC vs USDT, BTC is converted at market rate with 1 confirmation, and the wallet-registration/updateWallet semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Add verification credits to the current API key') and immediately narrows the input to a tx hash for a payment already sent. This clearly distinguishes it from siblings like insumer_buy_key, insumer_buy_merchant_credits, and insumer_confirm_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes the precondition clearly ('a payment the caller has already sent', 'it submits the transaction hash'), which tells the agent this is a post-payment submission step. It does not, however, explicitly name the related sibling tool (e.g. insumer_confirm_payment or insumer_buy_key) as an alternative, so routing is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_buy_keyRegister a paid API keyInspect
Register a new API key against a USDC, USDT, BTC, or USDT-TRC20 payment the caller has already sent (no auth required, no email). This tool does not move funds: it submits the transaction hash. Receiving addresses: EVM 0xAd982CB19aCCa2923Df8F687C0614a7700255a23, Solana 6a1mLjefhvSJX1sEX8PTnionbE9DqoYjU6F6bNkT4Ydr, Tron TC5yvwkAMakkXtUxYiu2Yn1xbBcwYuD6cn, Bitcoin bc1qg7qnerdhlmdn899zemtez5tcx2a2snc0dt9dt0 (1 confirmation required). USDC/USDT auto-detected from the transaction; BTC converted to USD at market rate. One key per wallet; existing keys are topped up with a credit purchase instead. Non-refundable. Current prices and volume discounts: https://insumermodel.com/pricing/
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Stablecoin amount sent (minimum 5). Not required for BTC: USD value derived from on-chain amount at market rate. | |
| txHash | Yes | Transaction hash proving payment | |
| appName | Yes | Name for the API key (e.g. your agent or app name) | |
| chainId | Yes | Payment chain: 1, 8453, 137, 42161, 10, 56, 43114, 'solana', 'bitcoin', or 'tron'. EVM/Solana accept USDC and USDT (auto-detected). Bitcoin accepts BTC (converted to USD at market rate). Tron accepts USDT-TRC20. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
insumer_buy_merchant_creditsAdd credits to the store owner key from a paymentDestructiveInspect
Kept for compatibility: a store has no credit balance of its own, so a payment submitted here adds regular credits to the API key that owns the store, at a flat rate (the regular credit purchase, with volume tiers, is the usual way to top up). Submits a USDC, USDT, BTC, or USDT-TRC20 payment the caller has already sent. This tool does not move funds: it submits the transaction hash. USDC/USDT on EVM and Solana (auto-detected), USDT-TRC20 on Tron, BTC on Bitcoin (converted at market rate, 1 confirmation required). Non-refundable. Owner only. The first purchase registers the sender wallet to the API key; updateWallet: true replaces it. Current prices and volume discounts: https://insumermodel.com/pricing/
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Merchant ID | |
| amount | No | Stablecoin amount sent (minimum 5). Not required for BTC. | |
| txHash | Yes | Transaction hash proving payment | |
| chainId | Yes | Payment chain: 1, 8453, 137, 42161, 10, 56, 43114, 'solana', 'bitcoin', or 'tron'. EVM/Solana accept USDC and USDT (auto-detected). Bitcoin accepts BTC (converted to USD at market rate). Tron accepts USDT-TRC20. | |
| updateWallet | No | Set true to replace the registered sender wallet |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
insumer_check_discountCheck a discount (free)ARead-onlyIdempotentInspect
Calculate discount for a wallet at a merchant. Checks on-chain balances and returns tier and discount percentage per token, never raw balance amounts. Free: does not consume credits. Takes an EVM, Solana or XRPL wallet. An rpc_failure error (503) means a read did not complete: retry, and never treat it as not eligible. The check carries no proof of wallet control, so totalDiscount is what an unproven wallet gets; walletTerms gives the store's terms, and discountIfProven (when present) is what signing would get.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | No | EVM wallet address (0x...) | |
| merchant | Yes | Merchant ID | |
| xrplWallet | No | XRPL wallet address (r-address) | |
| solanaWallet | No | Solana wallet address (base58) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds substantial context beyond them: it never returns raw balances, consumes no credits, exposes totalDiscount vs discountIfProven, and clarifies that no proof of wallet control is carried. The 503 retry semantics are a genuinely useful behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and cost, then error semantics, then the discount-field caveats. Dense but each sentence carries information; the discountIfProven/walletTerms sentence is somewhat packed but still earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and full annotation coverage, the description supplies the remaining interpretive context an agent needs — cost model, error retry rule, unproven-wallet caveat — so nothing material is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning by stating the wallet input may be EVM, Solana, or XRPL — clarifying that the three wallet-typed properties are mutually exclusive chain alternatives rather than additive inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource+scope: 'Calculate discount for a wallet at a merchant,' with the chain coverage and the free/no-credit trait stated. It is clearly distinguishable from siblings like insumer_wallet_trust or insumer_attest, which do not compute merchant discounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operating context: it is free, accepts EVM/Solana/XRPL wallets, and that a 503 rpc_failure means retry rather than treat as ineligible. It does not, however, state when to prefer this over a sibling such as insumer_wallet_trust or insumer_attest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_compliance_templatesList compliance templatesARead-onlyIdempotentInspect
List the compliance templates available for EAS attestation conditions. Each template carries pre-configured schema IDs, attester addresses, and decoder contracts for a KYC or identity provider (Coinbase Verifications on Base, Gitcoin Passport on Optimism), so a condition can name the template instead of raw EAS parameters. No authentication or credits required.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description still adds real value beyond them by stating "No authentication or credits required," which affects whether the agent can call this freely as a discovery step.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and then the payload contents; all clauses carry information (field list, provider examples, cost model). The second sentence is somewhat dense with parentheticals, which is a minor readability cost rather than waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return structure need not be explained, and the description still names the meaningful fields and concrete provider examples (Coinbase Verifications on Base, Gitcoin Passport on Optimism). Combined with the zero-parameter schema, this is complete enough for an agent to call correctly, with only the number/ordering of results left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly adds nothing about parameters because there are none to describe, keeping it consistent with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ("List the compliance templates") and immediately scopes it to EAS attestation conditions, making it clearly distinct from siblings like insumer_attest or insumer_wallet_trust. It also enumerates what a template contains (schema IDs, attester addresses, decoder contracts), so the agent knows exactly what kind of object it gets back.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the purpose of the tool: fetching templates so a condition can "name the template instead of raw EAS parameters," which tells the agent when this lookup is warranted. It does not name an alternative tool or an explicit when-not condition, but the usage context is unambiguous for a zero-argument listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_configure_nftsConfigure merchant NFTs (replaces)ADestructiveIdempotentInspect
Configure the NFT collections a merchant recognizes, each granting a discount or recognition only. Replaces the existing NFT configuration. Max 4 collections. Discounts are whole numbers from 1 to 50; a value with decimals is refused. Owner only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Merchant ID | |
| nftCollections | Yes | NFT collection configurations (0-4) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=true, so the replace semantics are partly carried by structured data. The description still adds substantive context: the 4-collection cap, that 'recognition' grants no discount, that decimal discounts are refused, and that the caller must be the owner. It stops short of describing what happens to previously configured collections beyond the replacement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the core action and the destructive replace behavior. Every sentence carries a distinct constraint (scope, replace, cap, validation, authorization) with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the annotations cover the safety profile. The description completes the picture with permission requirements, cardinality limits, and value validation. Minor gaps remain around failure modes and whether omitted collections are deleted outright.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both top-level parameters and all nested fields are already documented in the schema, including the discount 1-50 range, taxon, chainId enum, and enabled carry-through rule. The description restates the discount integer constraint and the 4-item cap but adds no format or syntax detail beyond the schema, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Configure the NFT collections a merchant recognizes') and immediately quantifies scope (max 4, discount-or-recognition only). It is distinguishable from the sibling insumer_configure_tokens by naming NFTs explicitly, though no sibling is called out by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes the key operational fact that this is a replace, not an append ('Replaces the existing NFT configuration'), and states 'Owner only'. It does not, however, say when to choose this tool over insumer_configure_tokens or insumer_configure_settings, nor does it give explicit when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_configure_settingsUpdate merchant settingsADestructiveIdempotentInspect
Update merchant settings: discount stacking mode, cap, the store's terms for wallets sent without proof of control, and stablecoin payment configuration. All fields optional; supplied fields replace their current values. discountCap is a whole number from 1 to 100. A wallet with proof gets the full discount their holdings earn, without the daily limit for unproven buyers. Owner only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Merchant ID | |
| discountCap | No | Maximum total discount percentage: a whole number from 1 to 100, no decimals | |
| usdcPayment | No | USDC payment settings, or null to disable | |
| discountMode | No | 'highest' uses best single discount, 'stack' adds them together, 'capped' stacks up to discountCap | |
| maxUnprovenDiscount | No | Most a wallet without proof of control can get, in percent: 0 = no discount, null = the same as a proven wallet | |
| maxDiscountsPerWalletPerDay | No | Discount codes per UTC day for a wallet without proof of control; null = no limit |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, openWorldHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: the owner-only authorization requirement and the replacement semantics of supplied fields, which matter for a destructive partial update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the resource and field list, then the update rules and the discountCap constraint. Dense but each sentence carries information; only the wallet-proof sentence is slightly tangential to calling the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described, and the annotations carry the safety profile. The description covers scope, permissions and update semantics adequately for a 6-parameter, owner-restricted mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining the interplay of discountMode/discountCap and how proven versus unproven wallets are treated — semantics the enum and range descriptions alone do not fully convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (update merchant settings) and enumerates the exact configurable domains — discount stacking mode, cap, unproven-wallet terms, stablecoin payments. This clearly separates it from siblings like insumer_configure_tokens and insumer_configure_nfts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear precondition ("Owner only") and the partial-update contract ("All fields optional; supplied fields replace their current values"), so the agent knows when and how to call it. It does not, however, name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_configure_tokensConfigure merchant tokens (replaces)ADestructiveIdempotentInspect
Configure merchant token discount tiers. Set own token and/or partner tokens. Replaces the existing token configuration. Max 8 tokens total. Tier discounts are whole numbers from 1 to 50; a value with decimals is refused. Owner only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Merchant ID | |
| ownToken | No | Merchant's own token configuration, or null to remove | |
| partnerTokens | No | Partner token configurations |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, but the description adds real behavioral context: the operation replaces existing config, is capped at a max of 8 tokens, requires ownership, and refuses decimal discount values. That owner-only authorization constraint and the replace-destroys-prior-state detail are not derivable from the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short sentences with zero filler, front-loading the verb/resource and the destructive replace semantic before the numeric limits and the authorization requirement. Every sentence carries a distinct constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and the description covers the replace risk, ownership, token count cap and discount validation. It is slightly thin on what a validation failure or partial alsoOn removal looks like, though the schema's alsoOn note partially covers the latter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents id, ownToken, partnerTokens and all nested constraints, including the 1-50 whole-number discount and the 8-item cap. The description restates the 8-token maximum and discount rule without adding syntax or format detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Configure merchant token discount tiers') and names the two sub-resources it writes (own token and partner tokens). The title's '(replaces)' flag is reinforced in the body, so the agent understands this is an overwrite, not an append. It does not name distinct siblings such as insumer_configure_nfts or insumer_configure_settings, so sibling disambiguation is left to the resource noun.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource and the 'Owner only' note, but the description never says when to prefer this over insumer_configure_nfts/insumer_configure_settings, nor when to skip it entirely. There is no explicit when-not guidance or named alternative, leaving the agent to infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_confirm_paymentConfirm a discount paymentIdempotentInspect
Confirm the USDC payment for an INSR discount code. The server verifies the on-chain transaction receipt.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Discount code (e.g. INSR-A7K3M) | |
| amount | Yes | USDC amount sent | |
| txHash | Yes | On-chain transaction hash or Solana signature | |
| chainId | Yes | Chain where the USDC was sent: EVM chain ID (1, 8453, 137, 42161, 10, 56, 43114) or 'solana'. Bitcoin and Tron are not accepted here. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
insumer_create_merchantCreate a merchantInspect
Create a new merchant, owned by the API key that creates it. The store has no credit balance of its own: that key pays for the store's codes, scans and taps, and credits in the response is that key's balance. Limited number of merchants per API key.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| location | No | City or region | |
| companyId | Yes | Unique merchant ID (alphanumeric, dashes, underscores) | |
| companyName | Yes | Company display name |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
insumer_creditsCheck credit balanceARead-onlyIdempotentInspect
Check verification credit balance, tier, and daily rate limit for the current API key.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by enumerating what is returned (balance, tier, daily rate limit) and that it is key-scoped, but it says nothing about rate limiting on the check itself or how the daily limit is reset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence that identifies the action, the subject, and the key scoping with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with an output schema and full annotation coverage, the description supplies everything needed to invoke it correctly. The only shortfall is the missing tie-in to the credit-purchasing siblings, which is a usage rather than completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. Schema description coverage is also 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Check') plus the exact resource ('verification credit balance, tier, and daily rate limit') and scopes it to the current API key. It is clearly distinguishable from siblings like insumer_buy_credits or insumer_buy_key, though it never names them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, and the natural alternatives (insumer_buy_credits, insumer_buy_merchant_credits) are never referenced. The agent must infer that this is a pre-purchase check rather than being told so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_get_merchantGet a merchant profileARead-onlyIdempotentInspect
Get full public merchant profile including token tiers, NFT collections, discount mode, verification status, and walletTerms: what the store gives a wallet with and without proof of control, so you can decide whether to sign before creating a code.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Merchant ID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so safety and idempotency are fully covered structurally. The description adds context about what the profile contains (walletTerms, verification status) but does not disclose behavioral traits beyond the field enumeration — no auth requirements, rate limits, or caching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb+resource and then enumerates the payload and the decision context. It is information-dense without waste, though the clause after 'so you can decide' is slightly run-on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter, full schema coverage, annotations covering safety/idempotency, and an output schema that presumably documents the return shape, the description does not need to explain return values. It covers purpose, payload contents, and the decision context. Slight gaps remain around alternatives and when-not-to-use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (id) with 100% schema description coverage and a pattern constraint. The description adds no parameter-level detail, but with a single well-documented parameter and full schema coverage, this is adequate — baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Get full public merchant profile') and enumerates the payload fields (token tiers, NFT collections, discount mode, verification status, walletTerms). It does not name any sibling tool for differentiation, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is an implied usage context — 'so you can decide whether to sign before creating a code' — which tells the agent when this data is relevant (pre-signing decisions). But there is no explicit when-to-use statement, no mention of alternatives like insumer_list_merchants for browsing, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_jwksGet public signing keysARead-onlyIdempotentInspect
Get InsumerAPI's public signing keys as a JWKS (JSON Web Key Set): an ECDSA P-256 key under its kids, followed by the ML-DSA-65 post-quantum key as RFC 9964 AKP entries. Signatures on attestation and trust responses verify against these keys. Match an entry by the kid (or pqKid) on the response, never by position; an unknown kid is unverifiable, not refuted. No authentication required.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, openWorld, and non-destructive, so the bar is lower; the description still adds real behavioral context beyond them — 'No authentication required' and the rule that matching must be by kid/pqKid, with an unknown kid being 'unverifiable, not refuted.' It does not describe caching or rotation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and appropriately short for a zero-parameter tool. The single dense sentence packs several distinct facts (key types, verification use, matching rule, no auth), which is efficient though slightly overloaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return structure needn't be explained, yet the description still adds the key-identity semantics that the schema alone wouldn't convey. Nothing needed to invoke the tool correctly is missing; only optional context like key rotation cadence is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so baseline is 4. The description's mention of kid/pqKid is about the response payload, not inputs, and the empty schema needs no compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get InsumerAPI's public signing keys as a JWKS') and enumerates the key types returned (ECDSA P-256, ML-DSA-65 AKP). It is unmistakably distinct from the attest/trust/compliance siblings, which all consume these keys rather than fetch them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for use: 'Signatures on attestation and trust responses verify against these keys,' implying this is the verification prerequisite. However, it never explicitly names alternatives or states when-not to call it, so it stops short of the explicit routing a 5 requires.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_list_merchantsList merchantsARead-onlyIdempotentInspect
Browse merchants in the public directory. Filter by accepted token, verification status. Returns company name, website, tokens accepted, discount info, and walletTerms (the store's terms with and without proof of wallet control).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (default 50, max 200) | |
| token | No | Filter by accepted token symbol, e.g. 'UNI' | |
| offset | No | Pagination offset (default 0) | |
| verified | No | Filter by domain verification status |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety profile is covered. Description adds useful return-field context (walletTerms explanation) beyond annotations, but doesn't mention pagination behavior or default result size, which are relevant for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then filters, then return values. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return-field details needn't be repeated, but the description does a good job summarizing key fields anyway. Missing pagination behavior for a list tool is a minor gap given params cover limit/offset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully documents all four parameters including defaults, ranges, and enum. The description adds no syntax or format details beyond what the schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Browse merchants in the public directory.' Clearly distinguishes from sibling insumer_get_merchant (singular fetch) by scoping to listing/browsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions filtering by token and verification status but gives no when-to-use guidance or alternatives. An agent would need to infer that insumer_get_merchant should be used for a single merchant rather than listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_list_tokensList registered tokensARead-onlyIdempotentInspect
List the tokens and NFT collections listed in the Insumer registry. Filter by chain, symbol, or asset type. The registry is a directory, not the list of what can be checked: an attestation can check any token on a supported chain, and NFTs on EVM chains, Solana and XRPL, whether listed or not. An empty result means nothing is listed under that filter, not that the token is unsupported.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by asset type | |
| chain | No | Filter by chain ID | |
| symbol | No | Filter by token symbol |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, destructiveHint and openWorldHint, so the safety bar is lower. The description adds real value beyond them by disclosing empty-result semantics and the non-exhaustive nature of the registry, which prevents a common misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the core action before the interpretive caveats. Each sentence earns its place, though the 'not the list of what can be checked' point is restated in slightly different phrasing in the following sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and rich annotations, the description needn't cover return values. Combined with the safety annotations and full schema coverage, the definition gives the agent everything needed to call and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the three filter parameters (type, chain, symbol) are already documented in the schema. The description restates the filter axes without adding format or edge-case detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (tokens and NFT collections in the Insumer registry) with clear scope. It distinguishes itself from the check/attest siblings by framing the registry as a directory rather than the set of checkable assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong guidance on interpretation: 'The registry is a directory, not the list of what can be checked' and 'An empty result means nothing is listed under that filter, not that the token is unsupported.' This tells the agent when not to conclude lack of support, but it does not explicitly name sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_merchant_statusGet merchant status (owner)Read-onlyIdempotentInspect
Get full private merchant details: credits (the owner key's balance), token configs, NFT collections, directory status, verification status, payment settings. Owner only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Merchant ID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
insumer_publish_directoryPublish directory listingAIdempotentInspect
Publish or refresh the merchant's listing in the public directory from its current tokens and settings. Owner only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Merchant ID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare write (readOnlyHint=false), idempotent, non-destructive, and open-world. The description adds the meaningful extra context that the caller must be the owner and that publication is public-facing and republished from existing state rather than ad-hoc input. It stops short of noting failure modes (e.g., what blocks publication).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler; the action and scope come first and the authorization constraint is appended compactly at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, full schema coverage, an existing output schema, and annotations covering the safety/idempotency profile, the description covers what an agent needs. Minor gaps remain around prerequisites and what a failed publish looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single `id` parameter is fully documented as the merchant ID with a pattern and length bound. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb pair (publish/refresh), the exact resource (merchant's listing in the public directory), and the data source (current tokens and settings). No sibling tool touches directory publication, so the agent can immediately distinguish it from configure_tokens, configure_settings, or verify_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Owner only" gives a clear permission gate, and "refresh ... from its current tokens and settings" implies the tool should follow configuration steps. However, it never explicitly says when to call it versus alternatives such as re-running configure_tokens, nor states prerequisites (e.g., verified domain) as an exclusion condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_request_domain_verificationRequest domain verificationAInspect
Request a domain verification token for a merchant. Returns the token and three ways to place it: DNS TXT record, HTML meta tag, or file upload. Verified merchants get a trust badge in the public directory. Owner only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Merchant ID | |
| domain | Yes | Domain to verify (e.g. 'example.com') |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, idempotent=false, destructive=false, and openWorld=true, so the safety profile is covered. The description adds useful context beyond that: what the call returns (token + three placement mechanisms), the auth constraint ('Owner only'), and the downstream benefit (trust badge in the public directory). It does not mention rate limits or token expiry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: what is requested, what comes back, and the permission gate. Front-loaded with the core action and no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be restated (though the description helpfully summarizes them). With annotations covering the mutation/safety profile and the description adding the owner-only constraint and outcome, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (id and domain), so the schema carries the semantics. The description adds no syntax, format, or constraint detail beyond what the schema already provides, which is the baseline 3 case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('Request a domain verification token for a merchant') with concrete output detail (token plus DNS TXT, HTML meta tag, or file upload). It does not explicitly contrast with the closely related sibling insumer_verify_domain, so sibling differentiation rests largely on the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Owner only' note gives a prerequisite/permission gate, and the description implies the tool is a first step before verification. However, it never states when to call this versus insumer_verify_domain or what to do after placing the token, leaving workflow routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_setupCreate a free API keyAInspect
Generate a free-tier InsumerAPI key (insr_live_...). No credit card required. The user adds the key to their MCP config as INSUMER_API_KEY and restarts. One free key per email, with a per-IP daily limit. Free-tier allowance: https://insumermodel.com/pricing/
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address for the API key | ||
| appName | No | Name of your app or project (default: 'MCP Agent') |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations covering only the safety profile (readOnlyHint false, idempotentHint false, openWorldHint true), the description supplies the substantive behavior: it is a non-idempotent one-per-email issuance, subject to a per-IP daily quota, requires no payment, and requires a config edit plus restart. Rate limits and quota constraints are disclosed, which is exactly what the annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short sentences, front-loaded with what is generated and the cost, then the post-call action, constraints, and a reference link. Every sentence carries distinct information with no repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation in prose. The description covers the remaining gaps an agent needs: cost, key format, quota limits, and the required follow-up (inject as INSUMER_API_KEY and restart). Nothing material is missing for a two-parameter setup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so email and appName are already documented in the schema. The description reinforces that email drives the one-key-per-email rule but says nothing about appName or its default, so it adds only marginal meaning. Baseline 3 applies when the schema carries the parameter load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Generate a free-tier InsumerAPI key') plus the artifact format (insr_live_...), so the agent knows exactly what is produced. It implicitly separates itself from the paid sibling insumer_buy_key via 'free-tier' and 'No credit card required', but never names an alternative, so sibling differentiation is inferential rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when this is used (agent needs a key for MCP config, then restarts) and states real constraints: one free key per email and a per-IP daily limit. It stops short of naming alternatives such as insumer_buy_key for higher allowances, so there is no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_ucp_discountDiscount in UCP formatInspect
Check token-holder discount eligibility in Google Universal Commerce Protocol (UCP) format. Returns title, extension field, and applied array compatible with UCP checkout flows. The on-chain check is the same one behind INSR discount codes, wrapped in UCP format. A code that carries a discount costs one credit from the API key that owns the store; a 0% result is free. A caller using another key is not charged, and stores on a licensed platform are covered by its license. Paid discount codes requested with a key other than the store's owner are subject to an hourly limit (429; the message says when to try again). Takes an EVM, Solana or XRPL wallet. An rpc_failure error (503) means a read did not complete and nothing was signed: retry, and never treat it as a no. Optional walletProof proves you control the EVM wallet: the response then says walletProven true, and the full discount its holdings earn applies, without the store's daily limit for unproven wallets. Without it the store's terms for unproven wallets apply, and discountIfProven shows what a proof would get.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | Optional line items for per-item cent-amount allocations | |
| wallet | No | EVM wallet address (0x...) | |
| merchantId | Yes | Merchant ID | |
| xrplWallet | No | XRPL wallet address (r-address) | |
| walletProof | No | Optional proof that you control 'wallet' (EVM only; send it without solanaWallet or xrplWallet). Sign this EIP-4361 message with the wallet, within 5 minutes, with a nonce you never reused: api.insumermodel.com wants you to sign in with your Ethereum account: <wallet> Prove wallet for a discount. URI: https://api.insumermodel.com/v1/merchants/<merchantId> Version: 1 Chain ID: 1 Nonce: <8+ random letters or digits> Issued At: <ISO 8601 time now> A proven wallet gets the full discount its holdings earn (under the store's tiers and cap), without the daily limit for unproven wallets. Without it, the store's terms for unproven wallets apply (see walletTerms on the merchant). A proof that fails returns 401 and uses no credit. Smart-contract wallets are not accepted yet. | |
| solanaWallet | No | Solana wallet address (base58) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
insumer_validate_codeValidate a discount codeARead-onlyIdempotentInspect
Validate an INSR-XXXXX discount code. For merchant backends during ACP/UCP checkout to confirm code validity, discount percent, and expiry. Returns valid/invalid status with reason, and walletProven (whether the code went to a caller that proved control of the wallet). No authentication required, no credits consumed. Does not expose wallet or token data.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Discount code in INSR-XXXXX format |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds significant context beyond them: no authentication required, no credits consumed, return shape (valid/invalid with reason, walletProven), and a data privacy guarantee ('Does not expose wallet or token data'). This is a rich behavioral disclosure that goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action and followed by context, return info, and constraints. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description still summarizes the return values (valid/invalid status, reason, walletProven), which helps the agent understand the outcome. It covers authentication, cost, side effects, and privacy. Complete for a validation tool with one parameter and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema documents the single parameter with a pattern and description. The description mentions the INSR-XXXXX format, which is redundant with the schema, and adds no extra semantic detail about the parameter beyond what is already provided. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Validate) and resource (INSR-XXXXX discount code), and explicitly scopes it to merchant backends during ACP/UCP checkout. This distinguishes it from siblings like insumer_check_discount or insumer_attest by naming the exact format and use context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states the context ('For merchant backends during ACP/UCP checkout') and the purpose ('confirm code validity, discount percent, and expiry'). This tells when to use it, though it does not explicitly name an alternative tool (e.g., insumer_check_discount) or state when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insumer_verifyCreate a discount codeInspect
Create a signed discount code (INSR-XXXXX, 30-minute expiry) for a wallet at a merchant. Returns tier and discount percentage, never raw balance amounts. A code that carries a discount costs one credit from the API key that owns the store; a 0% result is free. A caller using another key is not charged, and stores on a licensed platform are covered by its license. Paid discount codes requested with a key other than the store's owner are subject to an hourly limit (429; the message says when to try again). If the merchant has Stripe Connect, a coupon is auto-created. Takes an EVM, Solana or XRPL wallet. An rpc_failure error (503) means a read did not complete and no code was issued: retry, and never treat it as a no. Optional walletProof proves you control the EVM wallet: the response then says walletProven true, and the full discount its holdings earn applies, without the store's daily limit for unproven wallets. Without it the store's terms for unproven wallets apply, and discountIfProven shows what a proof would get.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | No | EVM wallet address (0x...) | |
| merchantId | Yes | Merchant ID | |
| xrplWallet | No | XRPL wallet address (r-address) | |
| walletProof | No | Optional proof that you control 'wallet' (EVM only; send it without solanaWallet or xrplWallet). Sign this EIP-4361 message with the wallet, within 5 minutes, with a nonce you never reused: api.insumermodel.com wants you to sign in with your Ethereum account: <wallet> Prove wallet for a discount. URI: https://api.insumermodel.com/v1/merchants/<merchantId> Version: 1 Chain ID: 1 Nonce: <8+ random letters or digits> Issued At: <ISO 8601 time now> A proven wallet gets the full discount its holdings earn (under the store's tiers and cap), without the daily limit for unproven wallets. Without it, the store's terms for unproven wallets apply (see walletTerms on the merchant). A proof that fails returns 401 and uses no credit. Smart-contract wallets are not accepted yet. | |
| solanaWallet | No | Solana wallet address (base58) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
insumer_verify_domainVerify domain ownershipIdempotentInspect
Check a merchant's previously requested domain verification token. The server looks for it as a DNS TXT record, HTML meta tag, or uploaded file, and marks the domain verified when found. Rate limited per merchant (429 says when to retry). Owner only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Merchant ID |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
insumer_wallet_trustWallet trust profile (signed)AInspect
Generate a signed wallet trust fact profile for an EVM wallet: a curated set of presence checks organized into dimensions (stablecoins, governance, nfts, staking, institutional_stablecoins, tokenized_treasuries, stablecoin_deposits, wrapped_bitcoin, names, account): 155 base checks across 27 chains in 10 dimensions. Optional Solana, XRPL, Bitcoin and Tron wallets add their own dimensions, up to 176 checks across 29 chains in 14 dimensions; optional Stellar and Sui wallets let rows inside existing dimensions evaluate. Dimensions arrive in a fixed order: the base dimensions as listed, then any of solana, xrpl, bitcoin and tron that were switched on, in that order. The account dimension holds two rows per chain on Ethereum, Base, Arbitrum, Optimism and Polygon: contract code at the wallet address, and an EIP-7702 delegation there; a plain key reads false on both, and which contract is never named. Rows on a chain whose wallet is not supplied stay in the signed profile with evaluated: false. Every check is held or not held (present or not present in the account dimension), never a balance. The signed conditionSetVersion (currently 2026-10-08) names the check list that was run; log it, never reject on it. Returns per-dimension pass/fail counts and an overall summary: no score, no opinion. Designed for AI agent-to-agent trust decisions. Costs 3 credits (6 with proof: 'merkle'). An rpc_failure error (503) means a read did not complete and nothing was signed: retry, and never treat it as a no. Current chain and check counts: https://insumermodel.com/llms.txt
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| proof | No | Set to 'merkle' for EIP-1186 Merkle storage proofs on EVM token checks (6 credits). Rows whose balance is computed rather than stored (Aave aTokens, BUIDL), NFT/non-EVM rows and the account rows are declined with a reason (an account proof is available from the attest tool's account_code condition); the premium is refunded whenever no proof is delivered. | |
| wallet | Yes | EVM wallet address (0x...) to profile | |
| suiWallet | No | Sui wallet address (0x + 64 hex). If provided, lets the rows on Sui evaluate. Adds no dimension. | |
| tronWallet | No | Tron wallet address (T-prefixed). If provided, adds the Tron dimension. | |
| xrplWallet | No | XRPL wallet address (r-address). If provided, adds the XRPL dimension and lets the institutional row on XRPL evaluate. | |
| solanaWallet | No | Solana wallet address (base58). If provided, adds the Solana dimension and lets the institutional rows on Solana evaluate. | |
| bitcoinWallet | No | Bitcoin address. If provided, adds the Bitcoin dimension (native BTC presence). | |
| stellarWallet | No | Stellar wallet address (G-prefixed). If provided, lets the institutional rows on Stellar evaluate (classic trustlines). Adds no dimension. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | No | true when the API call succeeded |
| data | No | The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records |
| keys | No | JWKS entries (insumer_jwks) |
| meta | No | Response metadata such as version and timestamp |
| error | No | Error details when ok is false |
| items | No | The result when the endpoint returns a JSON array |
| message | No | A plain-text result (insumer_setup), or a message from the API |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far exceeds the annotations: discloses cost (3 credits, 6 with proof), the rpc_failure 503 semantics ('nothing was signed... never treat it as a no'), conditionSetVersion handling ('log it, never reject on it'), fixed dimension ordering, and that rows on unsupplied wallets remain with evaluated:false. No contradiction with readOnlyHint=false, which is consistent with a credit-charging, signing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Long, but the purpose is front-loaded in the first clause and each subsequent sentence carries non-obvious operational facts (ordering, costs, error semantics). The dimension enumeration and chain/check counts are somewhat list-heavy and could be trimmed given a canonical llms.txt link is supplied.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter, credit-charging, signing tool this covers everything an agent needs: cost, failure/retry semantics, version field handling, partial-evaluation behavior, and the distinction between 'no score, no opinion' output. Completeness is high even though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the fixed arrival order of dimensions (base list, then solana/xrpl/bitcoin/tron) and which wallets add dimensions vs. only enable row evaluation. It does not add per-parameter syntax the schema lacks, so it is not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Generate a signed wallet trust fact profile for an EVM wallet') and immediately scopes what the profile contains (155 base checks across 27 chains in 10 dimensions). The EVM-singular scope cleanly distinguishes it from batch_wallet_trust and from the attest sibling, both visible in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear deployment context ('Designed for AI agent-to-agent trust decisions') and states precisely when the optional per-chain wallet params change behavior (add a dimension vs. merely let rows evaluate). It stops short of naming when to prefer batch_wallet_trust or insumer_attest, so no explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.21.1- Changed
insumer_attest2 fields changed- changed
Input schema / properties / conditions / descriptionPrevious value: -"1-10 on-chain conditions to verify"New value: +"The list of 1 to 10 conditions to evaluate. All of them are read in this one call and covered by the one signed attestation." - changed
Input schema / properties / conditions / items / properties / delegation / descriptionPrevious value: -"Required for erc7710_delegation. The signed ERC-7710 delegation to evaluate. Met iff ALL of: attested wallet is the delegate; declared delegator is expectedDelegator; EIP-712 signature verifies (EOA or ERC-1271); unrevoked at the anchored block; every caveat enforcer recognized; any time-window caveat currently satisfied. Recognized enforcers: timestamp (evaluated), erc20_transfer_amount, native_transfer_amount, allowed_targets, limited_calls (the last four are REPORTED as declaredLimits: redemption enforces them, the attestation does not simulate enforcement)."New value: +"Required for erc7710_delegation. The signed ERC-7710 delegation to evaluate. Met iff ALL of: attested wallet is the delegate; declared delegator is expectedDelegator; EIP-712 signature verifies (EOA or ERC-1271); unrevoked at the anchored block; every caveat enforcer recognized; any time-window caveat currently satisfied. Recognized enforcers: timestamp (evaluated), erc20_transfer_amount, native_transfer_amount, allowed_targets, limited_calls (the last four are REPORTED as declaredLimits: redemption enforces them, the attestation does not simulate enforcement). A delegation result that is not met carries failReason, and an attestation that includes a delegation condition expires in 5 minutes instead of 30."
5 tool updates
v1.17.2- Changed
insumer_attest11 fields changed- changed
Input schema / properties / conditions / items / properties / agentId / descriptionPrevious value: -"Required for erc8004_agent. The ERC-8004 agent ID as a uint256 decimal string — the caller must supply it (the deployed Identity Registry has no wallet-to-agentId reverse lookup). Met iff the attested wallet owns the agent NFT (ownerOf) or is the registry's signature-verified agentWallet binding. Registry 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 on Base; chainId 8453 only. Honest semantics: registration is permissionless minting — the signed statement implies no vetting, no reputation, no endorsement."New value: +"Required for erc8004_agent. The ERC-8004 agent ID as a uint256 decimal string; the caller must supply it (the deployed Identity Registry has no wallet-to-agentId reverse lookup). Met iff the attested wallet owns the agent NFT (ownerOf) or is the registry's signature-verified agentWallet binding. Registry 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 on Base; chainId 8453 only. Honest semantics: registration is permissionless minting, so the signed statement implies no vetting, no reputation, no endorsement." - added
Input schema / properties / conditions / items / properties / delegateAdded value: +{ + "$ref": "#/properties/wallet", + "description": "For account_code with expect 'eip7702' only (a 400 with any other expect): an EVM address; met iff the wallet's EIP-7702 designator points at it. Echoed in lowercase inside the signed evaluatedCondition as the caller's input; the actual delegation target is never returned." +} - changed
Input schema / properties / conditions / items / properties / delegation / descriptionPrevious value: -"Required for erc7710_delegation. The signed ERC-7710 delegation to evaluate. Met iff ALL of: attested wallet is the delegate; declared delegator is expectedDelegator; EIP-712 signature verifies (EOA or ERC-1271); unrevoked at the anchored block; every caveat enforcer recognized; any time-window caveat currently satisfied. Recognized enforcers: timestamp (evaluated), erc20_transfer_amount, native_transfer_amount, allowed_targets, limited_calls (the last four are REPORTED as declaredLimits — redemption enforces them, the attestation does not simulate enforcement)."New value: +"Required for erc7710_delegation. The signed ERC-7710 delegation to evaluate. Met iff ALL of: attested wallet is the delegate; declared delegator is expectedDelegator; EIP-712 signature verifies (EOA or ERC-1271); unrevoked at the anchored block; every caveat enforcer recognized; any time-window caveat currently satisfied. Recognized enforcers: timestamp (evaluated), erc20_transfer_amount, native_transfer_amount, allowed_targets, limited_calls (the last four are REPORTED as declaredLimits: redemption enforces them, the attestation does not simulate enforcement)." - changed
Input schema / properties / conditions / items / properties / delegation / properties / caveats / descriptionPrevious value: -"Caveats the principal signed (max 16). Every enforcer must be recognized or the condition fails — no override."New value: +"Caveats the principal signed (max 16). Every enforcer must be recognized or the condition fails, with no override." - changed
Input schema / properties / conditions / items / properties / delegationManager / descriptionPrevious value: -"Required for erc7710_delegation. DelegationManager contract the delegation was signed against — one of the recognized MetaMask Delegation Framework managers on Base (current default 0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3). chainId 8453 only."New value: +"Required for erc7710_delegation. DelegationManager contract the delegation was signed against: one of the recognized MetaMask Delegation Framework managers on Base (current default 0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3). chainId 8453 only." - added
Input schema / properties / conditions / items / properties / expectAdded value: +{ + "description": "Required for account_code: the code state the wallet address itself must be in at the anchored block. 'none' is no code (a plain key account); 'eip7702' is the EIP-7702 delegation designator (a key that has delegated execution to a contract); 'contract' is any other code (a smart-contract wallet, a protocol, a token). The three states are exclusive on a chain. EVM chains only; a non-EVM chainId is rejected with a 400. The result is met or not met, like every type: the code and the delegation target are never returned, in any format or mode. The signed evaluatedCondition is {type, chainId, expect, operator: 'code_state'}. With proof 'merkle', the proof is an EIP-1186 account proof (subject 'account_code') whose codeHash is the proven value.", + "enum": [ + "none", + "eip7702", + "contract" + ], + "type": "string" +} - changed
Input schema / properties / conditions / items / properties / expectedDelegator / descriptionPrevious value: -"Required for erc7710_delegation. The principal address the caller asserts authorized this agent. The condition fails unless the delegation's declared delegator matches — without it a self-delegation would read as authority, so there is no structural-only mode."New value: +"Required for erc7710_delegation. The principal address the caller asserts authorized this agent. The condition fails unless the delegation's declared delegator matches. Without it a self-delegation would read as authority, so there is no structural-only mode." - changed
Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"Condition type: token_balance, nft_ownership (EVM, Solana and XRPL), eas_attestation, farcaster_id (Farcaster IdRegistry on Optimism), evm_view_call (single-address-argument view function returning bool; RPC EVM chains only), ratio_to_amount (balance >= multiple * amount; RPC EVM chains only), ratio_to_supply (balance / totalSupply >= minFraction; RPC EVM chains, ERC-20 only), erc8004_agent (registered ERC-8004 agent on Base; agentId required), or erc7710_delegation (signed MetaMask-framework delegation validity on Base; delegationManager, expectedDelegator, and delegation required; max 3 per request)"New value: +"Condition type: token_balance, nft_ownership (EVM, Solana and XRPL), eas_attestation, farcaster_id (Farcaster IdRegistry on Optimism), evm_view_call (single-address-argument view function returning bool; EVM chains only), ratio_to_amount (balance >= multiple * amount; EVM chains only), ratio_to_supply (balance / totalSupply >= minFraction; EVM chains, ERC-20 only), erc8004_agent (registered ERC-8004 agent on Base; agentId required), erc7710_delegation (signed MetaMask-framework delegation validity on Base; delegationManager, expectedDelegator, and delegation required; max 3 per request), or account_code (the code state of the wallet address itself on an EVM chain; expect required, delegate optional with expect 'eip7702'; no contractAddress)" - changed
Input schema / properties / conditions / items / properties / type / enumPrevious value: -[ - "token_balance", - "nft_ownership", - "eas_attestation", - "farcaster_id", - "evm_view_call", - "ratio_to_amount", - "ratio_to_supply", - "erc8004_agent", - "erc7710_delegation" -]New value: +[ + "token_balance", + "nft_ownership", + "eas_attestation", + "farcaster_id", + "evm_view_call", + "ratio_to_amount", + "ratio_to_supply", + "erc8004_agent", + "erc7710_delegation", + "account_code" +] - changed
Input schema / properties / proof / descriptionPrevious value: -"Set to 'merkle' for EIP-1186 Merkle storage proofs (2 credits). For token_balance on supported EVM chains (not ZKsync Era, Sei, Viction or XDC Network, and not on non-EVM chains); for erc7710_delegation, a storage proof of the revocation slot (subject 'delegation_revocation') on managers with an on-chain-verified layout."New value: +"Set to 'merkle' for EIP-1186 Merkle proofs (2 credits, refunded to 1 when no proof is delivered). For token_balance or ratio_to_amount against an ERC-20, a storage proof of the balance slot (no subject field); for the same conditions with contractAddress 'native', an account proof whose balance field is the value evaluated (subject 'account_balance'); for account_code, an account proof whose codeHash is the value evaluated (subject 'account_code'); for erc7710_delegation, a storage proof of the revocation slot (subject 'delegation_revocation') on managers with an on-chain-verified layout. Supported EVM chains only (not ZKsync Era, Sei, Viction or XDC Network, and not on non-EVM chains)." - changed
Input schema / properties / stellarWallet / descriptionPrevious value: -"Stellar wallet address (G-prefixed). For verifying XLM or trustline assets (USDC, BENJI, etc.). Use chainId 'stellar' with the asset issuer's G-address as contractAddress and pass assetCode (e.g. 'USDC'). Soroban contract balances not visible — classic trustlines only."New value: +"Stellar wallet address (G-prefixed). For verifying XLM or trustline assets (USDC, BENJI, etc.). Use chainId 'stellar' with the asset issuer's G-address as contractAddress and pass assetCode (e.g. 'USDC'). Soroban contract balances not visible; classic trustlines only."
- Changed
insumer_batch_wallet_trust1 field changed- added
Input schema / properties / detailAdded value: +{ + "description": "'summary' (default): the text is a short summary per wallet and the complete signed profiles are in structuredContent. 'full': the complete signed profiles as text too, tens of thousands of characters per wallet (more with optional wallets or merkle proofs). Choose it on the call that needs it: profiles cannot be fetched again, so a second call signs fresh profiles and is charged again. Not sent to the API; it does not change the price of the call.", + "enum": [ + "summary", + "full" + ], + "type": "string" +}
- Changed
insumer_buy_key1 field changed- changed
Input schema / properties / amount / descriptionPrevious value: -"Stablecoin amount sent (minimum 5). Not required for BTC — USD value derived from on-chain amount at market rate."New value: +"Stablecoin amount sent (minimum 5). Not required for BTC: USD value derived from on-chain amount at market rate."
- Changed
insumer_confirm_payment3 fields changed- changed
Input schema / properties / amount / descriptionPrevious value: -"Stablecoin amount sent"New value: +"USDC amount sent" - changed
Input schema / properties / chainId / anyOfPrevious value: -[ - { - "enum": [ - "1", - "8453", - "137", - "42161", - "10", - "56", - "43114" - ], - "type": "string" - }, - { - "type": "integer" - }, - { - "const": "solana", - "type": "string" - }, - { - "const": "tron", - "type": "string" - } -]New value: +[ + { + "enum": [ + "1", + "8453", + "137", + "42161", + "10", + "56", + "43114" + ], + "type": "string" + }, + { + "type": "integer" + }, + { + "const": "solana", + "type": "string" + } +] - changed
Input schema / properties / chainId / descriptionPrevious value: -"Payment chain: EVM chain ID (1, 8453, 137, 42161, 10, 56, 43114), 'solana', or 'tron'"New value: +"Chain where the USDC was sent: EVM chain ID (1, 8453, 137, 42161, 10, 56, 43114) or 'solana'. Bitcoin and Tron are not accepted here."
- Changed
insumer_wallet_trust1 field changed- changed
Input schema / properties / proof / descriptionPrevious value: -"Set to 'merkle' for EIP-1186 Merkle storage proofs on EVM token checks (6 credits). Rows whose balance is computed rather than stored (Aave aTokens, BUIDL) and NFT/non-EVM rows are declined with a reason; the premium is refunded whenever no proof is delivered."New value: +"Set to 'merkle' for EIP-1186 Merkle storage proofs on EVM token checks (6 credits). Rows whose balance is computed rather than stored (Aave aTokens, BUIDL), NFT/non-EVM rows and the account rows are declined with a reason (an account proof is available from the attest tool's account_code condition); the premium is refunded whenever no proof is delivered."
8 tool updates
v1.17.1- Changed
insumer_acp_discount4 fields changed- removed
Input schema / properties / stellarWalletRemoved value: -{ - "description": "Stellar wallet address (G-prefixed)", - "pattern": "^G[A-Z2-7]{55}$", - "type": "string" -} - removed
Input schema / properties / suiWalletRemoved value: -{ - "description": "Sui wallet address (0x + 64 hex)", - "pattern": "^0x[0-9a-fA-F]{64}$", - "type": "string" -} - removed
Input schema / properties / tronWalletRemoved value: -{ - "description": "Tron wallet address (T-prefixed)", - "pattern": "^T[1-9A-HJ-NP-Za-km-z]{33}$", - "type": "string" -} - added
Input schema / properties / walletProofAdded value: +{ + "additionalProperties": false, + "description": "Optional proof that you control 'wallet' (EVM only; send it without solanaWallet or xrplWallet). Sign this EIP-4361 message with the wallet, within 5 minutes, with a nonce you never reused:\napi.insumermodel.com wants you to sign in with your Ethereum account:\n<wallet>\n\nProve wallet for a discount.\n\nURI: https://api.insumermodel.com/v1/merchants/<merchantId>\nVersion: 1\nChain ID: 1\nNonce: <8+ random letters or digits>\nIssued At: <ISO 8601 time now>\nA proven wallet gets the full discount its holdings earn (under the store's tiers and cap), without the daily limit for unproven wallets. Without it, the store's terms for unproven wallets apply (see walletTerms on the merchant). A proof that fails returns 401 and uses no credit. Smart-contract wallets are not accepted yet.", + "properties": { + "message": { + "description": "The EIP-4361 message, exactly as signed", + "maxLength": 4096, + "type": "string" + }, + "signature": { + "description": "The wallet's personal_sign (EIP-191) signature over the message", + "maxLength": 2000, + "pattern": "^0x[0-9a-fA-F]+$", + "type": "string" + } + }, + "required": [ + "message", + "signature" + ], + "type": "object" +}
- Changed
insumer_attest12 fields changed- added
Input schema / properties / conditions / items / properties / contractAddress / anyOfAdded value: +[ + { + "maxLength": 200, + "minLength": 1, + "pattern": "^[A-Za-z0-9:_]+$", + "type": "string" + }, + { + "maxLength": 600, + "pattern": "^0x[0-9a-fA-F]{1,64}::[A-Za-z_][A-Za-z0-9_]*::[A-Za-z_][A-Za-z0-9_]*<[A-Za-z0-9:_<>, ]+>$", + "type": "string" + } +] - changed
Input schema / properties / conditions / items / properties / contractAddress / descriptionPrevious value: -"Token or NFT contract address (required for token_balance, nft_ownership, ratio_to_amount, and ratio_to_supply; ratio_to_supply requires an ERC-20 contract, no native). 'native' means the chain's native coin and is for token_balance and ratio_to_amount only. nft_ownership needs the NFT contract address (0x + 40 hex on EVM); 'native' with nft_ownership is rejected with a 400, so use token_balance for the native coin. On Sui, pass a coin type address::module::Name: native SUI is '0x2::sui::SUI', and 'native' is not accepted there."New value: +"Token or NFT contract address (required for token_balance, nft_ownership, ratio_to_amount, and ratio_to_supply; ratio_to_supply requires an ERC-20 contract, no native). 'native' means the chain's native coin and is for token_balance and ratio_to_amount only. nft_ownership needs the NFT contract address (0x + 40 hex on EVM); 'native' with nft_ownership is rejected with a 400, so use token_balance for the native coin. On Sui, pass a coin type address::module::Name: native SUI is '0x2::sui::SUI', and 'native' is not accepted there. A coin type may carry type parameters in angle brackets." - removed
Input schema / properties / conditions / items / properties / contractAddress / maxLengthRemoved value: -200 - removed
Input schema / properties / conditions / items / properties / contractAddress / minLengthRemoved value: -1 - removed
Input schema / properties / conditions / items / properties / contractAddress / patternRemoved value: -"^[A-Za-z0-9:_]+$" - removed
Input schema / properties / conditions / items / properties / contractAddress / typeRemoved value: -"string" - changed
Input schema / properties / conditions / items / properties / currency / descriptionPrevious value: -"XRPL trust line currency code (e.g. 'RLUSD', 'USDC'). Required for XRPL trust line tokens, ignored for other chains."New value: +"XRPL trust line currency code (e.g. 'RLUSD'). Case-sensitive: enter it exactly as the issuer created it. Required for XRPL trust line tokens, ignored for other chains." - added
Input schema / properties / conditions / items / properties / currency / minLengthAdded value: +1 - changed
Input schema / properties / conditions / items / properties / currency / patternPrevious value: -"^[A-Za-z0-9]+$"New value: +"^[\\x20-\\x7E]+$" - changed
Input schema / properties / conditions / items / properties / taxon / descriptionPrevious value: -"XRPL NFToken taxon filter (optional, for nft_ownership on XRPL only). Filters NFTs by issuer + taxon."New value: +"XRPL NFToken taxon filter: an integer from 0 to 4294967295 (optional, for nft_ownership on XRPL only). Filters NFTs by issuer + taxon." - added
Input schema / properties / conditions / items / properties / taxon / maximumAdded value: +4294967295 - added
Input schema / properties / conditions / items / properties / taxon / minimumAdded value: +0
- Changed
insumer_check_discount3 fields changed- removed
Input schema / properties / stellarWalletRemoved value: -{ - "description": "Stellar wallet address (G-prefixed)", - "pattern": "^G[A-Z2-7]{55}$", - "type": "string" -} - removed
Input schema / properties / suiWalletRemoved value: -{ - "description": "Sui wallet address (0x + 64 hex)", - "pattern": "^0x[0-9a-fA-F]{64}$", - "type": "string" -} - removed
Input schema / properties / tronWalletRemoved value: -{ - "description": "Tron wallet address (T-prefixed)", - "pattern": "^T[1-9A-HJ-NP-Za-km-z]{33}$", - "type": "string" -}
- Changed
insumer_configure_nfts7 fields changed- added
Input schema / properties / nftCollections / items / properties / benefitTypeAdded value: +{ + "description": "'discount' (the default) grants the discount below. 'recognition' means holders are recognized and no discount is granted.", + "enum": [ + "discount", + "recognition" + ], + "type": "string" +} - changed
Input schema / properties / nftCollections / items / properties / discount / descriptionPrevious value: -"Discount percentage (1-50)"New value: +"Discount percentage: a whole number from 1 to 50, no decimals. Required unless benefitType is 'recognition'." - added
Input schema / properties / nftCollections / items / properties / enabledAdded value: +{ + "description": "true or false. false keeps the collection in the configuration but switched off. Leave it out for an enabled collection. When re-saving an existing configuration, carry each collection's enabled value through, or a collection that was switched off is switched back on.", + "type": "boolean" +} - changed
Input schema / properties / nftCollections / items / properties / taxon / descriptionPrevious value: -"XRPL NFT taxon for filtering by collection. Optional, XRPL only."New value: +"XRPL NFT taxon for filtering by collection: an integer from 0 to 4294967295. Optional, XRPL only." - added
Input schema / properties / nftCollections / items / properties / taxon / maximumAdded value: +4294967295 - added
Input schema / properties / nftCollections / items / properties / taxon / minimumAdded value: +0 - changed
Input schema / properties / nftCollections / items / requiredPrevious value: -[ - "name", - "contractAddress", - "chainId", - "discount" -]New value: +[ + "name", + "contractAddress", + "chainId" +]
- Changed
insumer_configure_settings3 fields changed- changed
Input schema / properties / discountCap / descriptionPrevious value: -"Maximum total discount percentage (1-100)"New value: +"Maximum total discount percentage: a whole number from 1 to 100, no decimals" - added
Input schema / properties / maxDiscountsPerWalletPerDayAdded value: +{ + "anyOf": [ + { + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "Discount codes per UTC day for a wallet without proof of control; null = no limit" +} - added
Input schema / properties / maxUnprovenDiscountAdded value: +{ + "anyOf": [ + { + "maximum": 100, + "minimum": 0, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "Most a wallet without proof of control can get, in percent: 0 = no discount, null = the same as a proven wallet" +}
- Changed
insumer_configure_tokens6 fields changed- changed
Input schema / properties / ownToken / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "chainId": { - "anyOf": [ - { - "enum": [ - "1", - "50", - "56", - "8453", - "43114", - "137", - "42161", - "10", - "88888", - "1868", - "98866", - "480", - "146", - "100", - "5000", - "534352", - "59144", - "324", - "81457", - "42220", - "204", - "130", - "57073", - "1329", - "80094", - "33139", - "4663", - "167000", - "2020", - "88", - "5042" - ], - "type": "string" - }, - { - "type": "integer" - }, - { - "const": "solana", - "type": "string" - }, - { - "const": "xrpl", - "type": "string" - } - ], - "description": "Merchant onboarding chain: one of the EVM chain IDs listed in this schema, 'solana', or 'xrpl'. Merchant token and NFT configs are not available on Bitcoin, Tron, Stellar or Sui." - }, - "contractAddress": { - "description": "Token contract address. For XRPL: use r-address issuer for trust line tokens, or 'native' for XRP.", - "maxLength": 200, - "minLength": 1, - "pattern": "^[A-Za-z0-9:_]+$", - "type": "string" - }, - "currency": { - "description": "XRPL trust line currency code (e.g. 'RLUSD', 'USDC', or 'USD'). Required for XRPL trust line tokens. Standard codes ≤ 3 chars; longer names like 'RLUSD' are auto hex-encoded by the API.", - "maxLength": 40, - "pattern": "^[A-Za-z0-9]+$", - "type": "string" - }, - "decimals": { - "description": "Token decimals (0-18). Required: the merchant registry stores it with each token and rejects a config without it. 6 for USDC, 18 for most ERC-20s.", - "maximum": 18, - "minimum": 0, - "type": "integer" - }, - "symbol": { - "description": "Token symbol, e.g. 'UNI'", - "maxLength": 10, - "type": "string" - }, - "tiers": { - "description": "1-4 discount tiers", - "items": { - "additionalProperties": false, - "properties": { - "discount": { - "description": "Discount percentage (1-50)", - "maximum": 50, - "minimum": 1, - "type": "integer" - }, - "name": { - "description": "Tier name, e.g. 'Gold', 'Silver'", - "maxLength": 30, - "type": "string" - }, - "threshold": { - "description": "Minimum token balance for this tier", - "exclusiveMinimum": 0, - "type": "number" - } - }, - "required": [ - "name", - "threshold", - "discount" - ], - "type": "object" - }, - "maxItems": 4, - "minItems": 1, - "type": "array" - } - }, - "required": [ - "symbol", - "chainId", - "contractAddress", - "decimals", - "tiers" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "alsoOn": { + "description": "Optional: the same token on other networks, up to 9 (EVM chains and Solana; not the XRP Ledger, not a native coin). The store decides which deployments count as the same token. Each network's balance is read in that token's own decimals there, the balances are added exactly, and the tier is awarded once. A read that fails on any listed network refuses the whole check (rpc_failure), never a partial total. When re-saving, carry each token's alsoOn through, or its other networks are removed.", + "items": { + "additionalProperties": false, + "properties": { + "chainId": { + "anyOf": [ + { + "exclusiveMinimum": 0, + "type": "integer" + }, + { + "const": "solana", + "type": "string" + } + ], + "description": "EVM chain ID, or 'solana'" + }, + "contractAddress": { + "description": "The same token's contract (EVM) or mint (Solana) on that network; not 'native'", + "maxLength": 64, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "chainId", + "contractAddress" + ], + "type": "object" + }, + "maxItems": 9, + "type": "array" + }, + "chainId": { + "anyOf": [ + { + "enum": [ + "1", + "50", + "56", + "8453", + "43114", + "137", + "42161", + "10", + "88888", + "1868", + "98866", + "480", + "146", + "100", + "5000", + "534352", + "59144", + "324", + "81457", + "42220", + "204", + "130", + "57073", + "1329", + "80094", + "33139", + "4663", + "167000", + "2020", + "88", + "5042" + ], + "type": "string" + }, + { + "type": "integer" + }, + { + "const": "solana", + "type": "string" + }, + { + "const": "xrpl", + "type": "string" + } + ], + "description": "Merchant onboarding chain: one of the EVM chain IDs listed in this schema, 'solana', or 'xrpl'. Merchant token and NFT configs are not available on Bitcoin, Tron, Stellar or Sui." + }, + "contractAddress": { + "description": "Token contract address. For XRPL: use r-address issuer for trust line tokens, or 'native' for XRP.", + "maxLength": 200, + "minLength": 1, + "pattern": "^[A-Za-z0-9:_]+$", + "type": "string" + }, + "currency": { + "description": "XRPL trust line currency code: a 3-character code (e.g. 'USD'), a token name of 1 to 20 printable ASCII characters (e.g. 'RLUSD'), or a 40-character hex code. Case-sensitive: send it exactly as the issuer created it. 'XRP' is the native coin and is not accepted here: use contractAddress 'native'. Required for XRPL trust line tokens.", + "maxLength": 40, + "minLength": 1, + "pattern": "^[\\x20-\\x7E]+$", + "type": "string" + }, + "decimals": { + "description": "Token decimals (0-18). Required: the merchant registry stores it with each token and rejects a config without it. 6 for USDC, 18 for most ERC-20s.", + "maximum": 18, + "minimum": 0, + "type": "integer" + }, + "enabled": { + "description": "true or false, never a string. false switches the own token off; leave it out or send true to keep it on.", + "type": "boolean" + }, + "logo": { + "description": "Logo URL for the token, shown in the public directory (max 500 characters). Optional.", + "maxLength": 500, + "type": "string" + }, + "name": { + "description": "Display name of the token, shown in the public directory (max 100 characters). Optional.", + "maxLength": 100, + "type": "string" + }, + "symbol": { + "description": "Token symbol, e.g. 'UNI'", + "maxLength": 10, + "type": "string" + }, + "tiers": { + "description": "1-4 discount tiers", + "items": { + "additionalProperties": false, + "properties": { + "discount": { + "description": "Discount percentage: a whole number from 1 to 50, no decimals", + "maximum": 50, + "minimum": 1, + "type": "integer" + }, + "name": { + "description": "Tier name, e.g. 'Gold', 'Silver'", + "maxLength": 30, + "type": "string" + }, + "threshold": { + "description": "Minimum token balance for this tier", + "exclusiveMinimum": 0, + "type": "number" + } + }, + "required": [ + "name", + "threshold", + "discount" + ], + "type": "object" + }, + "maxItems": 4, + "minItems": 1, + "type": "array" + } + }, + "required": [ + "symbol", + "chainId", + "contractAddress", + "decimals", + "tiers" + ], + "type": "object" + }, + { + "type": "null" + } +] - removed
Input schema / properties / partnerTokens / items / $refRemoved value: -"#/properties/ownToken/anyOf/0" - added
Input schema / properties / partnerTokens / items / additionalPropertiesAdded value: +false - added
Input schema / properties / partnerTokens / items / propertiesAdded value: +{ + "alsoOn": { + "$ref": "#/properties/ownToken/anyOf/0/properties/alsoOn" + }, + "chainId": { + "$ref": "#/properties/ownToken/anyOf/0/properties/chainId" + }, + "contractAddress": { + "$ref": "#/properties/ownToken/anyOf/0/properties/contractAddress" + }, + "currency": { + "$ref": "#/properties/ownToken/anyOf/0/properties/currency" + }, + "decimals": { + "$ref": "#/properties/ownToken/anyOf/0/properties/decimals" + }, + "logo": { + "$ref": "#/properties/ownToken/anyOf/0/properties/logo" + }, + "name": { + "$ref": "#/properties/ownToken/anyOf/0/properties/name" + }, + "symbol": { + "$ref": "#/properties/ownToken/anyOf/0/properties/symbol" + }, + "tiers": { + "$ref": "#/properties/ownToken/anyOf/0/properties/tiers" + } +} - added
Input schema / properties / partnerTokens / items / requiredAdded value: +[ + "symbol", + "chainId", + "contractAddress", + "decimals", + "tiers" +] - added
Input schema / properties / partnerTokens / items / typeAdded value: +"object"
- Changed
insumer_ucp_discount4 fields changed- removed
Input schema / properties / stellarWalletRemoved value: -{ - "description": "Stellar wallet address (G-prefixed)", - "pattern": "^G[A-Z2-7]{55}$", - "type": "string" -} - removed
Input schema / properties / suiWalletRemoved value: -{ - "description": "Sui wallet address (0x + 64 hex)", - "pattern": "^0x[0-9a-fA-F]{64}$", - "type": "string" -} - removed
Input schema / properties / tronWalletRemoved value: -{ - "description": "Tron wallet address (T-prefixed)", - "pattern": "^T[1-9A-HJ-NP-Za-km-z]{33}$", - "type": "string" -} - added
Input schema / properties / walletProofAdded value: +{ + "additionalProperties": false, + "description": "Optional proof that you control 'wallet' (EVM only; send it without solanaWallet or xrplWallet). Sign this EIP-4361 message with the wallet, within 5 minutes, with a nonce you never reused:\napi.insumermodel.com wants you to sign in with your Ethereum account:\n<wallet>\n\nProve wallet for a discount.\n\nURI: https://api.insumermodel.com/v1/merchants/<merchantId>\nVersion: 1\nChain ID: 1\nNonce: <8+ random letters or digits>\nIssued At: <ISO 8601 time now>\nA proven wallet gets the full discount its holdings earn (under the store's tiers and cap), without the daily limit for unproven wallets. Without it, the store's terms for unproven wallets apply (see walletTerms on the merchant). A proof that fails returns 401 and uses no credit. Smart-contract wallets are not accepted yet.", + "properties": { + "message": { + "description": "The EIP-4361 message, exactly as signed", + "maxLength": 4096, + "type": "string" + }, + "signature": { + "description": "The wallet's personal_sign (EIP-191) signature over the message", + "maxLength": 2000, + "pattern": "^0x[0-9a-fA-F]+$", + "type": "string" + } + }, + "required": [ + "message", + "signature" + ], + "type": "object" +}
- Changed
insumer_verify4 fields changed- removed
Input schema / properties / stellarWalletRemoved value: -{ - "description": "Stellar wallet address (G-prefixed)", - "pattern": "^G[A-Z2-7]{55}$", - "type": "string" -} - removed
Input schema / properties / suiWalletRemoved value: -{ - "description": "Sui wallet address (0x + 64 hex)", - "pattern": "^0x[0-9a-fA-F]{64}$", - "type": "string" -} - removed
Input schema / properties / tronWalletRemoved value: -{ - "description": "Tron wallet address (T-prefixed)", - "pattern": "^T[1-9A-HJ-NP-Za-km-z]{33}$", - "type": "string" -} - added
Input schema / properties / walletProofAdded value: +{ + "additionalProperties": false, + "description": "Optional proof that you control 'wallet' (EVM only; send it without solanaWallet or xrplWallet). Sign this EIP-4361 message with the wallet, within 5 minutes, with a nonce you never reused:\napi.insumermodel.com wants you to sign in with your Ethereum account:\n<wallet>\n\nProve wallet for a discount.\n\nURI: https://api.insumermodel.com/v1/merchants/<merchantId>\nVersion: 1\nChain ID: 1\nNonce: <8+ random letters or digits>\nIssued At: <ISO 8601 time now>\nA proven wallet gets the full discount its holdings earn (under the store's tiers and cap), without the daily limit for unproven wallets. Without it, the store's terms for unproven wallets apply (see walletTerms on the merchant). A proof that fails returns 401 and uses no credit. Smart-contract wallets are not accepted yet.", + "properties": { + "message": { + "description": "The EIP-4361 message, exactly as signed", + "maxLength": 4096, + "type": "string" + }, + "signature": { + "description": "The wallet's personal_sign (EIP-191) signature over the message", + "maxLength": 2000, + "pattern": "^0x[0-9a-fA-F]+$", + "type": "string" + } + }, + "required": [ + "message", + "signature" + ], + "type": "object" +}
27 tool updates
v1.16.0- Changed
insumer_acp_discount12 fields changed- added
Input schema / properties / items / items / properties / path / maxLengthAdded value: +200 - added
Input schema / properties / items / maxItemsAdded value: +100 - added
Input schema / properties / merchantId / maxLengthAdded value: +100 - added
Input schema / properties / merchantId / minLengthAdded value: +1 - added
Input schema / properties / merchantId / patternAdded value: +"^[a-zA-Z0-9_-]+$" - added
Input schema / properties / solanaWallet / patternAdded value: +"^[1-9A-HJ-NP-Za-km-z]{32,44}$" - added
Input schema / properties / stellarWalletAdded value: +{ + "description": "Stellar wallet address (G-prefixed)", + "pattern": "^G[A-Z2-7]{55}$", + "type": "string" +} - added
Input schema / properties / suiWalletAdded value: +{ + "description": "Sui wallet address (0x + 64 hex)", + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" +} - added
Input schema / properties / tronWalletAdded value: +{ + "description": "Tron wallet address (T-prefixed)", + "pattern": "^T[1-9A-HJ-NP-Za-km-z]{33}$", + "type": "string" +} - added
Input schema / properties / wallet / patternAdded value: +"^0x[0-9a-fA-F]{40}$" - added
Input schema / properties / xrplWallet / patternAdded value: +"^r[1-9A-HJ-NP-Za-km-z]{24,34}$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_attest39 fields changed- added
Input schema / properties / bitcoinWallet / patternAdded value: +"^(?:[13][1-9A-HJ-NP-Za-km-z]{25,34}|(?:bc1|BC1)[02-9ac-hj-np-zAC-HJ-NP-Z]{11,87})$" - added
Input schema / properties / conditions / items / properties / agentIdAdded value: +{ + "description": "Required for erc8004_agent. The ERC-8004 agent ID as a uint256 decimal string — the caller must supply it (the deployed Identity Registry has no wallet-to-agentId reverse lookup). Met iff the attested wallet owns the agent NFT (ownerOf) or is the registry's signature-verified agentWallet binding. Registry 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 on Base; chainId 8453 only. Honest semantics: registration is permissionless minting — the signed statement implies no vetting, no reputation, no endorsement.", + "pattern": "^\\d{1,78}$", + "type": "string" +} - added
Input schema / properties / conditions / items / properties / amountAdded value: +{ + "$ref": "#/properties/conditions/items/properties/threshold", + "description": "For ratio_to_amount: per-request reference amount in token/display units as a decimal string (e.g. \"100\" for 100 USDC, not base units/wei). Numbers are accepted and coerced. Must be > 0." +} - added
Input schema / properties / conditions / items / properties / assetCodeAdded value: +{ + "description": "Stellar trustline asset code (e.g. 'USDC', 'BENJI'). Required for Stellar non-native (trustline) tokens. Use contractAddress 'native' for XLM. Ignored for other chains. Flows into conditionHash so different assets on the same issuer produce different hashes.", + "pattern": "^[A-Za-z0-9]{1,12}$", + "type": "string" +} - added
Input schema / properties / conditions / items / properties / attester / $refAdded value: +"#/properties/wallet" - removed
Input schema / properties / conditions / items / properties / attester / typeRemoved value: -"string" - changed
Input schema / properties / conditions / items / properties / chainId / anyOfPrevious value: -[ - { - "description": "EVM chain ID", - "type": "integer" - }, - { - "const": "solana", - "type": "string" - }, - { - "const": "xrpl", - "type": "string" - }, - { - "const": "bitcoin", - "type": "string" - } -]New value: +[ + { + "description": "EVM chain ID", + "type": "integer" + }, + { + "const": "solana", + "type": "string" + }, + { + "const": "xrpl", + "type": "string" + }, + { + "const": "bitcoin", + "type": "string" + }, + { + "const": "tron", + "type": "string" + }, + { + "const": "stellar", + "type": "string" + }, + { + "const": "sui", + "type": "string" + } +] - changed
Input schema / properties / conditions / items / properties / chainId / descriptionPrevious value: -"Chain identifier: EVM chain ID (integer), 'solana', 'xrpl', or 'bitcoin'"New value: +"Chain identifier: EVM chain ID (integer, includes 50 for XDC), 'solana', 'xrpl', 'bitcoin', 'tron', 'stellar', or 'sui'" - changed
Input schema / properties / conditions / items / properties / contractAddress / descriptionPrevious value: -"Token or NFT contract address (required for token_balance and nft_ownership)"New value: +"Token or NFT contract address (required for token_balance, nft_ownership, ratio_to_amount, and ratio_to_supply; ratio_to_supply requires an ERC-20 contract, no native). 'native' means the chain's native coin and is for token_balance and ratio_to_amount only. nft_ownership needs the NFT contract address (0x + 40 hex on EVM); 'native' with nft_ownership is rejected with a 400, so use token_balance for the native coin. On Sui, pass a coin type address::module::Name: native SUI is '0x2::sui::SUI', and 'native' is not accepted there." - added
Input schema / properties / conditions / items / properties / contractAddress / maxLengthAdded value: +200 - added
Input schema / properties / conditions / items / properties / contractAddress / minLengthAdded value: +1 - added
Input schema / properties / conditions / items / properties / contractAddress / patternAdded value: +"^[A-Za-z0-9:_]+$" - added
Input schema / properties / conditions / items / properties / currency / maxLengthAdded value: +40 - added
Input schema / properties / conditions / items / properties / currency / patternAdded value: +"^[A-Za-z0-9]+$" - changed
Input schema / properties / conditions / items / properties / decimals / descriptionPrevious value: -"Token decimals (default 18)"New value: +"Optional. Leave it out: the token's own decimals are always read from the chain. If sent it is only a cross-check, and a value that differs from the token's own decimals is rejected with a 400." - added
Input schema / properties / conditions / items / properties / delegationAdded value: +{ + "additionalProperties": false, + "description": "Required for erc7710_delegation. The signed ERC-7710 delegation to evaluate. Met iff ALL of: attested wallet is the delegate; declared delegator is expectedDelegator; EIP-712 signature verifies (EOA or ERC-1271); unrevoked at the anchored block; every caveat enforcer recognized; any time-window caveat currently satisfied. Recognized enforcers: timestamp (evaluated), erc20_transfer_amount, native_transfer_amount, allowed_targets, limited_calls (the last four are REPORTED as declaredLimits — redemption enforces them, the attestation does not simulate enforcement).", + "properties": { + "authority": { + "description": "Root authority only (0xffff…ffff, 32 bytes of 0xff). Delegation chains are unsupported.", + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" + }, + "caveats": { + "description": "Caveats the principal signed (max 16). Every enforcer must be recognized or the condition fails — no override.", + "items": { + "additionalProperties": false, + "properties": { + "enforcer": { + "description": "Caveat enforcer contract address", + "pattern": "^0x[0-9a-fA-F]{40}$", + "type": "string" + }, + "terms": { + "description": "ABI-encoded caveat terms (hex)", + "maxLength": 20000, + "pattern": "^0x[0-9a-fA-F]*$", + "type": "string" + } + }, + "required": [ + "enforcer", + "terms" + ], + "type": "object" + }, + "maxItems": 16, + "type": "array" + }, + "delegate": { + "description": "Agent wallet the delegation authorizes. Must equal the attested wallet.", + "pattern": "^0x[0-9a-fA-F]{40}$", + "type": "string" + }, + "delegator": { + "description": "Principal address that signed the delegation. Must equal expectedDelegator.", + "pattern": "^0x[0-9a-fA-F]{40}$", + "type": "string" + }, + "salt": { + "anyOf": [ + { + "$ref": "#/properties/conditions/items/properties/agentId" + }, + { + "minimum": 0, + "type": "integer" + } + ], + "description": "Delegation salt (decimal string; numbers coerced)" + }, + "signature": { + "description": "EIP-712 signature over the delegation (hex). EOA recovery, or ERC-1271 for smart-contract principals.", + "maxLength": 20000, + "pattern": "^0x[0-9a-fA-F]*$", + "type": "string" + } + }, + "required": [ + "delegator", + "delegate", + "authority", + "caveats", + "salt", + "signature" + ], + "type": "object" +} - added
Input schema / properties / conditions / items / properties / delegationManagerAdded value: +{ + "$ref": "#/properties/wallet", + "description": "Required for erc7710_delegation. DelegationManager contract the delegation was signed against — one of the recognized MetaMask Delegation Framework managers on Base (current default 0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3). chainId 8453 only." +} - added
Input schema / properties / conditions / items / properties / expectedDelegatorAdded value: +{ + "$ref": "#/properties/wallet", + "description": "Required for erc7710_delegation. The principal address the caller asserts authorized this agent. The condition fails unless the delegation's declared delegator matches — without it a self-delegation would read as authority, so there is no structural-only mode." +} - added
Input schema / properties / conditions / items / properties / indexer / $refAdded value: +"#/properties/wallet" - removed
Input schema / properties / conditions / items / properties / indexer / typeRemoved value: -"string" - added
Input schema / properties / conditions / items / properties / minFractionAdded value: +{ + "$ref": "#/properties/conditions/items/properties/threshold", + "description": "For ratio_to_supply: required share of total supply, a decimal string in (0,1] (e.g. \"0.005\" for 0.5%). Met iff balance / totalSupply() >= minFraction. Numbers are accepted and coerced. For project/governance tokens, not stablecoins." +} - added
Input schema / properties / conditions / items / properties / multipleAdded value: +{ + "$ref": "#/properties/conditions/items/properties/threshold", + "description": "For ratio_to_amount: collateralization multiple as a decimal string (e.g. \"10\" for 'hold >= 10x the amount'). Met iff balance >= multiple * amount. Numbers are accepted and coerced. Must be > 0." +} - added
Input schema / properties / conditions / items / properties / schemaId / patternAdded value: +"^0x[0-9a-fA-F]{64}$" - added
Input schema / properties / conditions / items / properties / selectorAdded value: +{ + "description": "Required for evm_view_call. Canonical signature of a view function returning bool, in the form 'functionName(address)' (e.g. 'hasAccess(address)'). Single-address-argument view functions only; the 4-byte selector is derived from this signature.", + "maxLength": 100, + "pattern": "^[A-Za-z_][A-Za-z0-9_]*\\(address\\)$", + "type": "string" +} - added
Input schema / properties / conditions / items / properties / threshold / anyOfAdded value: +[ + { + "maxLength": 80, + "pattern": "^\\d+(\\.\\d+)?$", + "type": "string" + }, + { + "type": "number" + } +] - changed
Input schema / properties / conditions / items / properties / threshold / descriptionPrevious value: -"Minimum balance required (for token_balance). Must be > 0 when proof is merkle."New value: +"Minimum balance for token_balance, as a decimal string in token/display units (e.g. \"100\", not base units). Numbers are accepted and coerced to a string. Must be > 0 when proof is merkle." - removed
Input schema / properties / conditions / items / properties / threshold / typeRemoved value: -"number" - changed
Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"Condition type: token_balance, nft_ownership, eas_attestation, or farcaster_id (Farcaster IdRegistry on Optimism)"New value: +"Condition type: token_balance, nft_ownership (EVM, Solana and XRPL), eas_attestation, farcaster_id (Farcaster IdRegistry on Optimism), evm_view_call (single-address-argument view function returning bool; RPC EVM chains only), ratio_to_amount (balance >= multiple * amount; RPC EVM chains only), ratio_to_supply (balance / totalSupply >= minFraction; RPC EVM chains, ERC-20 only), erc8004_agent (registered ERC-8004 agent on Base; agentId required), or erc7710_delegation (signed MetaMask-framework delegation validity on Base; delegationManager, expectedDelegator, and delegation required; max 3 per request)" - changed
Input schema / properties / conditions / items / properties / type / enumPrevious value: -[ - "token_balance", - "nft_ownership", - "eas_attestation", - "farcaster_id" -]New value: +[ + "token_balance", + "nft_ownership", + "eas_attestation", + "farcaster_id", + "evm_view_call", + "ratio_to_amount", + "ratio_to_supply", + "erc8004_agent", + "erc7710_delegation" +] - added
Input schema / properties / declaredLimitsAdded value: +{ + "description": "Set to 'omit' to leave decoded caveat limits out of the signed results of erc7710_delegation conditions, so a forwarded attestation does not carry the principal's spending ceiling. met, delegationHash, and conditionHash are byte-identical either way.", + "enum": [ + "omit" + ], + "type": "string" +} - changed
Input schema / properties / format / descriptionPrevious value: -"Set to 'jwt' to include a Wallet Auth by InsumerAPI token (ES256-signed JWT) in the response. Verifiable by any standard JWT library using JWKS at /.well-known/jwks.json."New value: +"Set to 'jwt' to include a Wallet Auth by InsumerAPI token (ES256-signed JWT) in the response, with its ML-DSA-65 sibling pqJwt beside it. The jwt is verifiable by any standard JWT library using JWKS at /.well-known/jwks.json." - changed
Input schema / properties / proof / descriptionPrevious value: -"Set to 'merkle' for EIP-1186 Merkle storage proofs (2 credits). Proofs available for token_balance on RPC chains only."New value: +"Set to 'merkle' for EIP-1186 Merkle storage proofs (2 credits). For token_balance on supported EVM chains (not ZKsync Era, Sei, Viction or XDC Network, and not on non-EVM chains); for erc7710_delegation, a storage proof of the revocation slot (subject 'delegation_revocation') on managers with an on-chain-verified layout." - added
Input schema / properties / solanaWallet / patternAdded value: +"^[1-9A-HJ-NP-Za-km-z]{32,44}$" - added
Input schema / properties / stellarWalletAdded value: +{ + "description": "Stellar wallet address (G-prefixed). For verifying XLM or trustline assets (USDC, BENJI, etc.). Use chainId 'stellar' with the asset issuer's G-address as contractAddress and pass assetCode (e.g. 'USDC'). Soroban contract balances not visible — classic trustlines only.", + "pattern": "^G[A-Z2-7]{55}$", + "type": "string" +} - added
Input schema / properties / suiWalletAdded value: +{ + "description": "Sui wallet address (0x + 64 hex chars). For verifying SUI or other Sui coins (e.g. USDC). Use chainId 'sui' with the Sui coin type as contractAddress: '0x2::sui::SUI' for native SUI, or the full coin type address::module::Name for other coins. The string 'native' is not accepted on Sui.", + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" +} - added
Input schema / properties / tronWalletAdded value: +{ + "description": "Tron wallet address (T-prefixed, base58). For verifying TRX or TRC20 tokens (USDT-TRC20). Use chainId 'tron'.", + "pattern": "^T[1-9A-HJ-NP-Za-km-z]{33}$", + "type": "string" +} - added
Input schema / properties / wallet / patternAdded value: +"^0x[0-9a-fA-F]{40}$" - added
Input schema / properties / xrplWallet / patternAdded value: +"^r[1-9A-HJ-NP-Za-km-z]{24,34}$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_batch_wallet_trust11 fields changed- changed
Input schema / properties / wallets / items / properties / bitcoinWallet / descriptionPrevious value: -"Bitcoin address. Adds Bitcoin Holdings dimension."New value: +"Bitcoin address. Adds the Bitcoin dimension." - added
Input schema / properties / wallets / items / properties / bitcoinWallet / patternAdded value: +"^(?:[13][1-9A-HJ-NP-Za-km-z]{25,34}|(?:bc1|BC1)[02-9ac-hj-np-zAC-HJ-NP-Z]{11,87})$" - changed
Input schema / properties / wallets / items / properties / solanaWallet / descriptionPrevious value: -"Solana wallet address (base58). Adds USDC on Solana check."New value: +"Solana wallet address (base58). Adds the Solana dimension." - added
Input schema / properties / wallets / items / properties / solanaWallet / patternAdded value: +"^[1-9A-HJ-NP-Za-km-z]{32,44}$" - added
Input schema / properties / wallets / items / properties / stellarWalletAdded value: +{ + "description": "Stellar wallet address (G-prefixed). Lets the rows on Stellar evaluate; adds no dimension.", + "pattern": "^G[A-Z2-7]{55}$", + "type": "string" +} - added
Input schema / properties / wallets / items / properties / suiWalletAdded value: +{ + "description": "Sui wallet address (0x + 64 hex). Lets the rows on Sui evaluate; adds no dimension.", + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" +} - added
Input schema / properties / wallets / items / properties / tronWalletAdded value: +{ + "description": "Tron wallet address (T-prefixed). Adds the Tron dimension.", + "pattern": "^T[1-9A-HJ-NP-Za-km-z]{33}$", + "type": "string" +} - added
Input schema / properties / wallets / items / properties / wallet / patternAdded value: +"^0x[0-9a-fA-F]{40}$" - changed
Input schema / properties / wallets / items / properties / xrplWallet / descriptionPrevious value: -"XRPL wallet address (r-address). Adds RLUSD and USDC on XRPL checks."New value: +"XRPL wallet address (r-address). Adds the XRPL dimension." - added
Input schema / properties / wallets / items / properties / xrplWallet / patternAdded value: +"^r[1-9A-HJ-NP-Za-km-z]{24,34}$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_buy_credits6 fields changed- changed
Input schema / properties / chainId / anyOfPrevious value: -[ - { - "enum": [ - "1", - "8453", - "137", - "42161", - "10", - "56", - "43114" - ], - "type": "string" - }, - { - "type": "integer" - }, - { - "const": "solana", - "type": "string" - }, - { - "const": "bitcoin", - "type": "string" - } -]New value: +[ + { + "enum": [ + "1", + "8453", + "137", + "42161", + "10", + "56", + "43114" + ], + "type": "string" + }, + { + "type": "integer" + }, + { + "const": "solana", + "type": "string" + }, + { + "const": "bitcoin", + "type": "string" + }, + { + "const": "tron", + "type": "string" + } +] - changed
Input schema / properties / chainId / descriptionPrevious value: -"Payment chain: 1, 8453, 137, 42161, 10, 56, 43114, 'solana', or 'bitcoin'. EVM/Solana accept USDC and USDT (auto-detected). Bitcoin accepts BTC (converted to USD at market rate)."New value: +"Payment chain: 1, 8453, 137, 42161, 10, 56, 43114, 'solana', 'bitcoin', or 'tron'. EVM/Solana accept USDC and USDT (auto-detected). Bitcoin accepts BTC (converted to USD at market rate). Tron accepts USDT-TRC20." - added
Input schema / properties / txHash / maxLengthAdded value: +100 - added
Input schema / properties / txHash / patternAdded value: +"^(?:0x[0-9a-fA-F]{64}|[0-9a-fA-F]{64}|[1-9A-HJ-NP-Za-km-z]{43,90})$" - changed
Input schema / properties / updateWallet / descriptionPrevious value: -"Set true to update the registered sender wallet to this transaction's sender"New value: +"Set true to replace the registered sender wallet with this transaction's sender" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_buy_key5 fields changed- changed
Input schema / properties / chainId / anyOfPrevious value: -[ - { - "enum": [ - "1", - "8453", - "137", - "42161", - "10", - "56", - "43114" - ], - "type": "string" - }, - { - "type": "integer" - }, - { - "const": "solana", - "type": "string" - }, - { - "const": "bitcoin", - "type": "string" - } -]New value: +[ + { + "enum": [ + "1", + "8453", + "137", + "42161", + "10", + "56", + "43114" + ], + "type": "string" + }, + { + "type": "integer" + }, + { + "const": "solana", + "type": "string" + }, + { + "const": "bitcoin", + "type": "string" + }, + { + "const": "tron", + "type": "string" + } +] - changed
Input schema / properties / chainId / descriptionPrevious value: -"Payment chain: 1, 8453, 137, 42161, 10, 56, 43114, 'solana', or 'bitcoin'. EVM/Solana accept USDC and USDT (auto-detected). Bitcoin accepts BTC (converted to USD at market rate)."New value: +"Payment chain: 1, 8453, 137, 42161, 10, 56, 43114, 'solana', 'bitcoin', or 'tron'. EVM/Solana accept USDC and USDT (auto-detected). Bitcoin accepts BTC (converted to USD at market rate). Tron accepts USDT-TRC20." - added
Input schema / properties / txHash / maxLengthAdded value: +100 - added
Input schema / properties / txHash / patternAdded value: +"^(?:0x[0-9a-fA-F]{64}|[0-9a-fA-F]{64}|[1-9A-HJ-NP-Za-km-z]{43,90})$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_buy_merchant_credits9 fields changed- changed
Input schema / properties / chainId / anyOfPrevious value: -[ - { - "enum": [ - "1", - "8453", - "137", - "42161", - "10", - "56", - "43114" - ], - "type": "string" - }, - { - "type": "integer" - }, - { - "const": "solana", - "type": "string" - }, - { - "const": "bitcoin", - "type": "string" - } -]New value: +[ + { + "enum": [ + "1", + "8453", + "137", + "42161", + "10", + "56", + "43114" + ], + "type": "string" + }, + { + "type": "integer" + }, + { + "const": "solana", + "type": "string" + }, + { + "const": "bitcoin", + "type": "string" + }, + { + "const": "tron", + "type": "string" + } +] - changed
Input schema / properties / chainId / descriptionPrevious value: -"Payment chain: 1, 8453, 137, 42161, 10, 56, 43114, 'solana', or 'bitcoin'. EVM/Solana accept USDC and USDT (auto-detected). Bitcoin accepts BTC (converted to USD at market rate)."New value: +"Payment chain: 1, 8453, 137, 42161, 10, 56, 43114, 'solana', 'bitcoin', or 'tron'. EVM/Solana accept USDC and USDT (auto-detected). Bitcoin accepts BTC (converted to USD at market rate). Tron accepts USDT-TRC20." - added
Input schema / properties / id / maxLengthAdded value: +100 - added
Input schema / properties / id / minLengthAdded value: +1 - added
Input schema / properties / id / patternAdded value: +"^[a-zA-Z0-9_-]+$" - added
Input schema / properties / txHash / maxLengthAdded value: +100 - added
Input schema / properties / txHash / patternAdded value: +"^(?:0x[0-9a-fA-F]{64}|[0-9a-fA-F]{64}|[1-9A-HJ-NP-Za-km-z]{43,90})$" - changed
Input schema / properties / updateWallet / descriptionPrevious value: -"Set true to update the registered sender wallet"New value: +"Set true to replace the registered sender wallet" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_check_discount10 fields changed- added
Input schema / properties / merchant / maxLengthAdded value: +100 - added
Input schema / properties / merchant / minLengthAdded value: +1 - added
Input schema / properties / merchant / patternAdded value: +"^[a-zA-Z0-9_-]+$" - added
Input schema / properties / solanaWallet / patternAdded value: +"^[1-9A-HJ-NP-Za-km-z]{32,44}$" - added
Input schema / properties / stellarWalletAdded value: +{ + "description": "Stellar wallet address (G-prefixed)", + "pattern": "^G[A-Z2-7]{55}$", + "type": "string" +} - added
Input schema / properties / suiWalletAdded value: +{ + "description": "Sui wallet address (0x + 64 hex)", + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" +} - added
Input schema / properties / tronWalletAdded value: +{ + "description": "Tron wallet address (T-prefixed)", + "pattern": "^T[1-9A-HJ-NP-Za-km-z]{33}$", + "type": "string" +} - added
Input schema / properties / wallet / patternAdded value: +"^0x[0-9a-fA-F]{40}$" - added
Input schema / properties / xrplWallet / patternAdded value: +"^r[1-9A-HJ-NP-Za-km-z]{24,34}$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_compliance_templates1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_configure_nfts9 fields changed- added
Input schema / properties / id / maxLengthAdded value: +100 - added
Input schema / properties / id / minLengthAdded value: +1 - added
Input schema / properties / id / patternAdded value: +"^[a-zA-Z0-9_-]+$" - changed
Input schema / properties / nftCollections / items / properties / chainId / anyOfPrevious value: -[ - { - "enum": [ - "1", - "56", - "8453", - "43114", - "137", - "42161", - "10", - "88888", - "1868", - "98866", - "480", - "146", - "100", - "5000", - "534352", - "59144", - "324", - "81457", - "42220", - "1284", - "204", - "130", - "57073", - "1329", - "80094", - "33139", - "167000", - "2020", - "1285", - "88" - ], - "type": "string" - }, - { - "type": "integer" - }, - { - "const": "solana", - "type": "string" - }, - { - "const": "xrpl", - "type": "string" - }, - { - "const": "bitcoin", - "type": "string" - } -]New value: +[ + { + "enum": [ + "1", + "50", + "56", + "8453", + "43114", + "137", + "42161", + "10", + "88888", + "1868", + "98866", + "480", + "146", + "100", + "5000", + "534352", + "59144", + "324", + "81457", + "42220", + "204", + "130", + "57073", + "1329", + "80094", + "33139", + "4663", + "167000", + "2020", + "88", + "5042" + ], + "type": "string" + }, + { + "type": "integer" + }, + { + "const": "solana", + "type": "string" + }, + { + "const": "xrpl", + "type": "string" + } +] - changed
Input schema / properties / nftCollections / items / properties / chainId / descriptionPrevious value: -"Onboarding chain: any supported EVM chain ID (1, 56, 8453, 43114, 137, 42161, 10, 146, 100, 5000, 534352, 59144, 324, 81457, 42220, 1284, 204, 130, 57073, 1329, 80094, 33139, 88888, 1868, 98866, 480, 167000, 2020, 1285, 88), 'solana', 'xrpl', or 'bitcoin'"New value: +"Merchant onboarding chain: one of the EVM chain IDs listed in this schema, 'solana', or 'xrpl'. Merchant token and NFT configs are not available on Bitcoin, Tron, Stellar or Sui." - added
Input schema / properties / nftCollections / items / properties / contractAddress / maxLengthAdded value: +200 - added
Input schema / properties / nftCollections / items / properties / contractAddress / minLengthAdded value: +1 - added
Input schema / properties / nftCollections / items / properties / contractAddress / patternAdded value: +"^[A-Za-z0-9:_]+$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_configure_settings5 fields changed- added
Input schema / properties / id / maxLengthAdded value: +100 - added
Input schema / properties / id / minLengthAdded value: +1 - added
Input schema / properties / id / patternAdded value: +"^[a-zA-Z0-9_-]+$" - changed
Input schema / properties / usdcPayment / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "enabled": { - "description": "Enable or disable USDC payments", - "type": "boolean" - }, - "evmAddress": { - "description": "EVM wallet for USDC (0x...)", - "type": "string" - }, - "preferredChainId": { - "anyOf": [ - { - "enum": [ - "1", - "8453", - "137", - "42161", - "10", - "56", - "43114" - ], - "type": "string" - }, - { - "type": "integer" - }, - { - "const": "solana", - "type": "string" - } - ], - "description": "Preferred USDC chain" - }, - "solanaAddress": { - "description": "Solana wallet for USDC", - "type": "string" - } - }, - "required": [ - "enabled" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "enabled": { + "description": "Enable or disable USDC payments", + "type": "boolean" + }, + "evmAddress": { + "description": "EVM wallet for USDC (0x...)", + "pattern": "^0x[0-9a-fA-F]{40}$", + "type": "string" + }, + "preferredChainId": { + "anyOf": [ + { + "enum": [ + "1", + "8453", + "137", + "42161", + "10", + "56", + "43114" + ], + "type": "string" + }, + { + "type": "integer" + }, + { + "const": "solana", + "type": "string" + }, + { + "const": "tron", + "type": "string" + } + ], + "description": "Preferred USDC chain" + }, + "solanaAddress": { + "description": "Solana wallet for USDC", + "pattern": "^[1-9A-HJ-NP-Za-km-z]{32,44}$", + "type": "string" + } + }, + "required": [ + "enabled" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_configure_tokens6 fields changed- added
Input schema / properties / id / maxLengthAdded value: +100 - added
Input schema / properties / id / minLengthAdded value: +1 - added
Input schema / properties / id / patternAdded value: +"^[a-zA-Z0-9_-]+$" - changed
Input schema / properties / ownToken / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "chainId": { - "anyOf": [ - { - "enum": [ - "1", - "56", - "8453", - "43114", - "137", - "42161", - "10", - "88888", - "1868", - "98866", - "480", - "146", - "100", - "5000", - "534352", - "59144", - "324", - "81457", - "42220", - "1284", - "204", - "130", - "57073", - "1329", - "80094", - "33139", - "167000", - "2020", - "1285", - "88" - ], - "type": "string" - }, - { - "type": "integer" - }, - { - "const": "solana", - "type": "string" - }, - { - "const": "xrpl", - "type": "string" - }, - { - "const": "bitcoin", - "type": "string" - } - ], - "description": "Onboarding chain: any supported EVM chain ID (1, 56, 8453, 43114, 137, 42161, 10, 146, 100, 5000, 534352, 59144, 324, 81457, 42220, 1284, 204, 130, 57073, 1329, 80094, 33139, 88888, 1868, 98866, 480, 167000, 2020, 1285, 88), 'solana', 'xrpl', or 'bitcoin'" - }, - "contractAddress": { - "description": "Token contract address. For XRPL: use r-address issuer for trust line tokens, or 'native' for XRP.", - "type": "string" - }, - "currency": { - "description": "XRPL trust line currency code (e.g. 'RLUSD', 'USDC', or 'USD'). Required for XRPL trust line tokens. Standard codes ≤ 3 chars; longer names like 'RLUSD' are auto hex-encoded by the API.", - "type": "string" - }, - "decimals": { - "description": "Token decimals (0-18, default 18)", - "maximum": 18, - "minimum": 0, - "type": "integer" - }, - "symbol": { - "description": "Token symbol, e.g. 'UNI'", - "maxLength": 10, - "type": "string" - }, - "tiers": { - "description": "1-4 discount tiers", - "items": { - "additionalProperties": false, - "properties": { - "discount": { - "description": "Discount percentage (1-50)", - "maximum": 50, - "minimum": 1, - "type": "integer" - }, - "name": { - "description": "Tier name, e.g. 'Gold', 'Silver'", - "maxLength": 30, - "type": "string" - }, - "threshold": { - "description": "Minimum token balance for this tier", - "exclusiveMinimum": 0, - "type": "number" - } - }, - "required": [ - "name", - "threshold", - "discount" - ], - "type": "object" - }, - "maxItems": 4, - "minItems": 1, - "type": "array" - } - }, - "required": [ - "symbol", - "chainId", - "contractAddress", - "tiers" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "chainId": { + "anyOf": [ + { + "enum": [ + "1", + "50", + "56", + "8453", + "43114", + "137", + "42161", + "10", + "88888", + "1868", + "98866", + "480", + "146", + "100", + "5000", + "534352", + "59144", + "324", + "81457", + "42220", + "204", + "130", + "57073", + "1329", + "80094", + "33139", + "4663", + "167000", + "2020", + "88", + "5042" + ], + "type": "string" + }, + { + "type": "integer" + }, + { + "const": "solana", + "type": "string" + }, + { + "const": "xrpl", + "type": "string" + } + ], + "description": "Merchant onboarding chain: one of the EVM chain IDs listed in this schema, 'solana', or 'xrpl'. Merchant token and NFT configs are not available on Bitcoin, Tron, Stellar or Sui." + }, + "contractAddress": { + "description": "Token contract address. For XRPL: use r-address issuer for trust line tokens, or 'native' for XRP.", + "maxLength": 200, + "minLength": 1, + "pattern": "^[A-Za-z0-9:_]+$", + "type": "string" + }, + "currency": { + "description": "XRPL trust line currency code (e.g. 'RLUSD', 'USDC', or 'USD'). Required for XRPL trust line tokens. Standard codes ≤ 3 chars; longer names like 'RLUSD' are auto hex-encoded by the API.", + "maxLength": 40, + "pattern": "^[A-Za-z0-9]+$", + "type": "string" + }, + "decimals": { + "description": "Token decimals (0-18). Required: the merchant registry stores it with each token and rejects a config without it. 6 for USDC, 18 for most ERC-20s.", + "maximum": 18, + "minimum": 0, + "type": "integer" + }, + "symbol": { + "description": "Token symbol, e.g. 'UNI'", + "maxLength": 10, + "type": "string" + }, + "tiers": { + "description": "1-4 discount tiers", + "items": { + "additionalProperties": false, + "properties": { + "discount": { + "description": "Discount percentage (1-50)", + "maximum": 50, + "minimum": 1, + "type": "integer" + }, + "name": { + "description": "Tier name, e.g. 'Gold', 'Silver'", + "maxLength": 30, + "type": "string" + }, + "threshold": { + "description": "Minimum token balance for this tier", + "exclusiveMinimum": 0, + "type": "number" + } + }, + "required": [ + "name", + "threshold", + "discount" + ], + "type": "object" + }, + "maxItems": 4, + "minItems": 1, + "type": "array" + } + }, + "required": [ + "symbol", + "chainId", + "contractAddress", + "decimals", + "tiers" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Input schema / properties / partnerTokens / maxItemsAdded value: +8 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_confirm_payment9 fields changed- added
Input schema / properties / amount / anyOfAdded value: +[ + { + "maxLength": 80, + "pattern": "^\\d+(\\.\\d+)?$", + "type": "string" + }, + { + "type": "number" + } +] - removed
Input schema / properties / amount / typeRemoved value: -[ - "string", - "number" -] - changed
Input schema / properties / chainId / anyOfPrevious value: -[ - { - "enum": [ - "1", - "8453", - "137", - "42161", - "10", - "56", - "43114" - ], - "type": "string" - }, - { - "type": "integer" - }, - { - "const": "solana", - "type": "string" - } -]New value: +[ + { + "enum": [ + "1", + "8453", + "137", + "42161", + "10", + "56", + "43114" + ], + "type": "string" + }, + { + "type": "integer" + }, + { + "const": "solana", + "type": "string" + }, + { + "const": "tron", + "type": "string" + } +] - changed
Input schema / properties / chainId / descriptionPrevious value: -"Payment chain: EVM chain ID (1, 8453, 137, 42161, 10, 56, 43114) or 'solana'"New value: +"Payment chain: EVM chain ID (1, 8453, 137, 42161, 10, 56, 43114), 'solana', or 'tron'" - changed
Input schema / properties / code / descriptionPrevious value: -"Verification code from insumer_verify (e.g. INSR-A7K3M)"New value: +"Discount code (e.g. INSR-A7K3M)" - added
Input schema / properties / code / patternAdded value: +"^INSR-[A-Z0-9]{5}$" - added
Input schema / properties / txHash / maxLengthAdded value: +100 - added
Input schema / properties / txHash / patternAdded value: +"^(?:0x[0-9a-fA-F]{64}|[0-9a-fA-F]{64}|[1-9A-HJ-NP-Za-km-z]{43,90})$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_create_merchant1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_credits1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_get_merchant4 fields changed- added
Input schema / properties / id / maxLengthAdded value: +100 - added
Input schema / properties / id / minLengthAdded value: +1 - added
Input schema / properties / id / patternAdded value: +"^[a-zA-Z0-9_-]+$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_jwks1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_list_merchants2 fields changed- added
Input schema / properties / token / maxLengthAdded value: +32 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_list_tokens2 fields changed- added
Input schema / properties / symbol / maxLengthAdded value: +32 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_merchant_status4 fields changed- added
Input schema / properties / id / maxLengthAdded value: +100 - added
Input schema / properties / id / minLengthAdded value: +1 - added
Input schema / properties / id / patternAdded value: +"^[a-zA-Z0-9_-]+$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_publish_directory4 fields changed- added
Input schema / properties / id / maxLengthAdded value: +100 - added
Input schema / properties / id / minLengthAdded value: +1 - added
Input schema / properties / id / patternAdded value: +"^[a-zA-Z0-9_-]+$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_request_domain_verification6 fields changed- added
Input schema / properties / domain / maxLengthAdded value: +253 - added
Input schema / properties / domain / patternAdded value: +"^(?:[A-Za-z0-9](?:[A-Za-z0-9-]{0,61}[A-Za-z0-9])?\\.)+(?:[A-Za-z]{2,63}|xn--[A-Za-z0-9-]{1,59})$" - added
Input schema / properties / id / maxLengthAdded value: +100 - added
Input schema / properties / id / minLengthAdded value: +1 - added
Input schema / properties / id / patternAdded value: +"^[a-zA-Z0-9_-]+$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_setup2 fields changed- added
Input schema / properties / email / maxLengthAdded value: +254 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_ucp_discount12 fields changed- added
Input schema / properties / items / items / properties / path / maxLengthAdded value: +200 - added
Input schema / properties / items / maxItemsAdded value: +100 - added
Input schema / properties / merchantId / maxLengthAdded value: +100 - added
Input schema / properties / merchantId / minLengthAdded value: +1 - added
Input schema / properties / merchantId / patternAdded value: +"^[a-zA-Z0-9_-]+$" - added
Input schema / properties / solanaWallet / patternAdded value: +"^[1-9A-HJ-NP-Za-km-z]{32,44}$" - added
Input schema / properties / stellarWalletAdded value: +{ + "description": "Stellar wallet address (G-prefixed)", + "pattern": "^G[A-Z2-7]{55}$", + "type": "string" +} - added
Input schema / properties / suiWalletAdded value: +{ + "description": "Sui wallet address (0x + 64 hex)", + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" +} - added
Input schema / properties / tronWalletAdded value: +{ + "description": "Tron wallet address (T-prefixed)", + "pattern": "^T[1-9A-HJ-NP-Za-km-z]{33}$", + "type": "string" +} - added
Input schema / properties / wallet / patternAdded value: +"^0x[0-9a-fA-F]{40}$" - added
Input schema / properties / xrplWallet / patternAdded value: +"^r[1-9A-HJ-NP-Za-km-z]{24,34}$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_validate_code1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_verify10 fields changed- added
Input schema / properties / merchantId / maxLengthAdded value: +100 - added
Input schema / properties / merchantId / minLengthAdded value: +1 - added
Input schema / properties / merchantId / patternAdded value: +"^[a-zA-Z0-9_-]+$" - added
Input schema / properties / solanaWallet / patternAdded value: +"^[1-9A-HJ-NP-Za-km-z]{32,44}$" - added
Input schema / properties / stellarWalletAdded value: +{ + "description": "Stellar wallet address (G-prefixed)", + "pattern": "^G[A-Z2-7]{55}$", + "type": "string" +} - added
Input schema / properties / suiWalletAdded value: +{ + "description": "Sui wallet address (0x + 64 hex)", + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" +} - added
Input schema / properties / tronWalletAdded value: +{ + "description": "Tron wallet address (T-prefixed)", + "pattern": "^T[1-9A-HJ-NP-Za-km-z]{33}$", + "type": "string" +} - added
Input schema / properties / wallet / patternAdded value: +"^0x[0-9a-fA-F]{40}$" - added
Input schema / properties / xrplWallet / patternAdded value: +"^r[1-9A-HJ-NP-Za-km-z]{24,34}$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_verify_domain4 fields changed- added
Input schema / properties / id / maxLengthAdded value: +100 - added
Input schema / properties / id / minLengthAdded value: +1 - added
Input schema / properties / id / patternAdded value: +"^[a-zA-Z0-9_-]+$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
- Changed
insumer_wallet_trust12 fields changed- changed
Input schema / properties / bitcoinWallet / descriptionPrevious value: -"Bitcoin address. If provided, adds Bitcoin Holdings dimension (native BTC balance check)."New value: +"Bitcoin address. If provided, adds the Bitcoin dimension (native BTC presence)." - added
Input schema / properties / bitcoinWallet / patternAdded value: +"^(?:[13][1-9A-HJ-NP-Za-km-z]{25,34}|(?:bc1|BC1)[02-9ac-hj-np-zAC-HJ-NP-Z]{11,87})$" - changed
Input schema / properties / proof / descriptionPrevious value: -"Set to 'merkle' for EIP-1186 Merkle storage proofs on stablecoin/governance checks (6 credits)."New value: +"Set to 'merkle' for EIP-1186 Merkle storage proofs on EVM token checks (6 credits). Rows whose balance is computed rather than stored (Aave aTokens, BUIDL) and NFT/non-EVM rows are declined with a reason; the premium is refunded whenever no proof is delivered." - changed
Input schema / properties / solanaWallet / descriptionPrevious value: -"Solana wallet address (base58). If provided, adds USDC on Solana check."New value: +"Solana wallet address (base58). If provided, adds the Solana dimension and lets the institutional rows on Solana evaluate." - added
Input schema / properties / solanaWallet / patternAdded value: +"^[1-9A-HJ-NP-Za-km-z]{32,44}$" - added
Input schema / properties / stellarWalletAdded value: +{ + "description": "Stellar wallet address (G-prefixed). If provided, lets the institutional rows on Stellar evaluate (classic trustlines). Adds no dimension.", + "pattern": "^G[A-Z2-7]{55}$", + "type": "string" +} - added
Input schema / properties / suiWalletAdded value: +{ + "description": "Sui wallet address (0x + 64 hex). If provided, lets the rows on Sui evaluate. Adds no dimension.", + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" +} - added
Input schema / properties / tronWalletAdded value: +{ + "description": "Tron wallet address (T-prefixed). If provided, adds the Tron dimension.", + "pattern": "^T[1-9A-HJ-NP-Za-km-z]{33}$", + "type": "string" +} - added
Input schema / properties / wallet / patternAdded value: +"^0x[0-9a-fA-F]{40}$" - changed
Input schema / properties / xrplWallet / descriptionPrevious value: -"XRPL wallet address (r-address). If provided, adds RLUSD and USDC on XRPL checks."New value: +"XRPL wallet address (r-address). If provided, adds the XRPL dimension and lets the institutional row on XRPL evaluate." - added
Input schema / properties / xrplWallet / patternAdded value: +"^r[1-9A-HJ-NP-Za-km-z]{24,34}$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": true, + "properties": { + "data": { + "description": "The endpoint's payload: a signed attestation, trust profile, discount, merchant or token records" + }, + "error": { + "description": "Error details when ok is false" + }, + "items": { + "description": "The result when the endpoint returns a JSON array", + "items": {}, + "type": "array" + }, + "keys": { + "description": "JWKS entries (insumer_jwks)", + "items": {}, + "type": "array" + }, + "message": { + "description": "A plain-text result (insumer_setup), or a message from the API" + }, + "meta": { + "description": "Response metadata such as version and timestamp" + }, + "ok": { + "description": "true when the API call succeeded", + "type": "boolean" + } + }, + "type": "object" +}
27 tool updates
v0.1.0- Added
insumer_acp_discount - Added
insumer_attest - Added
insumer_batch_wallet_trust - Added
insumer_buy_credits - Added
insumer_buy_key - Added
insumer_buy_merchant_credits - Added
insumer_check_discount - Added
insumer_compliance_templates - Added
insumer_configure_nfts - Added
insumer_configure_settings - Added
insumer_configure_tokens - Added
insumer_confirm_payment - Added
insumer_create_merchant - Added
insumer_credits - Added
insumer_get_merchant - Added
insumer_jwks - Added
insumer_list_merchants - Added
insumer_list_tokens - Added
insumer_merchant_status - Added
insumer_publish_directory - Added
insumer_request_domain_verification - Added
insumer_setup - Added
insumer_ucp_discount - Added
insumer_validate_code - Added
insumer_verify - Added
insumer_verify_domain - Added
insumer_wallet_trust
TDQS
A3.7/5.0
Scored across 27 tools
Disambiguation4/5
Most tools target distinct resources or actions, and the extensive descriptions clarify boundaries (e.g., attest vs. wallet_trust, verify vs. check_discount). However, the four discount-related tools (verify, check_discount, acp_discount, ucp_discount) share the same underlying on-chain check and differ mainly in output format and credit cost, which could cause misselection.
Naming Consistency4/5
All 27 tools use the insumer_ prefix and snake_case, giving a highly predictable naming surface. Most follow a verb_noun pattern, though a few are noun phrases (wallet_trust, merchant_status, credits, jwks), a minor deviation.
Tool Count2/5
27 tools exceed the typical 3-15 range and the rubric's 25+ threshold for 'too many.' Several clusters (buy_key/buy_credits/buy_merchant_credits, configure_tokens/nfts/settings, acp/ucp discount wrappers) could be consolidated, suggesting the surface is over-expanded for the domain.
Completeness4/5
The server covers a wide domain: attestation, trust profiles, merchant directory and management, discount workflows, payments, domain verification, and key utilities. Minor gaps exist (no delete/update merchant profile, no API key rotation or listing), but core lifecycle operations are present.
Maintenance
ActivityActive
ResponsivenessWithin a week
Related MCP Connectors
Read-only on-chain verification and risk intelligence MCP for Web3 agents. BTC/ETH/XMR/ZEC live.
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Compliance MCP for AI agents: sanctions & KYT screening on 50+ chains, stablecoin-freeze, oracle.
Related MCP Servers
- AlicenseBqualityBmaintenanceMolTrust MCP Server provides AI agents with identity verification, reputation scoring, and verifiable credentials through W3C DID-based trust infrastructure. Includes ERC-8004 on-chain agent registration and Base blockchain anchoring for tamper-proof credential verification.48346 PyPI4MIT
- AlicenseAqualityDmaintenanceMCP server for AI agent trust verification, enabling agents to verify identities, check trust scores, and build reputation across multiple blockchain and web platforms.1210 npm1MIT
Syeniteofficial
FlicenseNot gradedqualityDmaintenanceA DeFi MCP server enabling AI agents to query lending rates, execute swaps/bridges, monitor positions, and access prediction markets across 30+ chains with a trust layer for calldata verification.-