Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
INSUMER_API_KEYYesInsumerAPI key. Get a free key at https://insumermodel.com/developers/

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
insumer_attestA

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

insumer_compliance_templatesA

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.

insumer_wallet_trustA

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

insumer_batch_wallet_trustA

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.

insumer_jwksA

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.

insumer_setupA

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/

insumer_verifyA

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.

insumer_list_merchantsA

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).

insumer_get_merchantA

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.

insumer_list_tokensA

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.

insumer_check_discountA

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.

insumer_creditsA

Check verification credit balance, tier, and daily rate limit for the current API key.

insumer_buy_keyA

Register a new API key against a USDC payment the caller has already sent (no auth required, no email). This tool does not move funds: it submits the transaction hash and a signature from the wallet that sent the payment. Paid in USDC only, on Ethereum, Optimism, BNB Chain, Polygon, Base, Arbitrum, Avalanche or Solana. Receiving addresses: 0xee432065474D2C852700f74e3fD81e2Bcc16a3D4 on Ethereum, Optimism, Polygon, Base, Arbitrum or Avalanche; 0xAd982CB19aCCa2923Df8F687C0614a7700255a23 on BNB Chain (USDC sent to it on the other EVM chains is also accepted during the changeover); 8fyEGM5tRjMocKQWaVXyM2XvvnTxR3sWdrYtug2zeLX4 on Solana (USDC sent to 6a1mLjefhvSJX1sEX8PTnionbE9DqoYjU6F6bNkT4Ydr is also accepted during the changeover). USDT, any other token and any other chain are refused and not credited. The sending wallet becomes the key's wallet: one key per wallet, and an existing key is topped up with a credit purchase instead. Non-refundable. Current prices and volume discounts: https://insumermodel.com/pricing/

insumer_buy_creditsA

Add verification credits to the current API key against a USDC payment the caller has already sent. This tool does not move funds: it submits the transaction hash. Paid in USDC only, on Ethereum, Optimism, BNB Chain, Polygon, Base, Arbitrum, Avalanche or Solana. Receiving addresses: 0xee432065474D2C852700f74e3fD81e2Bcc16a3D4 on Ethereum, Optimism, Polygon, Base, Arbitrum or Avalanche; 0xAd982CB19aCCa2923Df8F687C0614a7700255a23 on BNB Chain (USDC sent to it on the other EVM chains is also accepted during the changeover); 8fyEGM5tRjMocKQWaVXyM2XvvnTxR3sWdrYtug2zeLX4 on Solana (USDC sent to 6a1mLjefhvSJX1sEX8PTnionbE9DqoYjU6F6bNkT4Ydr is also accepted during the changeover). USDT, any other token and any other chain are refused and not credited. Non-refundable. The first purchase registers the sending wallet to the API key; later purchases must come from the same wallet, and updateWallet: true replaces the registered wallet. Registering or replacing the wallet takes senderSignature from the wallet that sent the payment; a payment from the registered wallet needs none. Current prices and volume discounts: https://insumermodel.com/pricing/

insumer_confirm_paymentB

Confirm the USDC payment for an INSR discount code. The server verifies the on-chain transaction receipt.

insumer_create_merchantA

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.

insumer_merchant_statusA

Get full private merchant details: credits (the owner key's balance), token configs, NFT collections, directory status, verification status, payment settings. Owner only.

insumer_configure_tokensA

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.

insumer_configure_nftsA

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.

insumer_configure_settingsA

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.

insumer_publish_directoryA

Publish or refresh the merchant's listing in the public directory from its current tokens and settings. Owner only.

insumer_buy_merchant_creditsA

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 payment the caller has already sent. This tool does not move funds: it submits the transaction hash. Paid in USDC only, on Ethereum, Optimism, BNB Chain, Polygon, Base, Arbitrum, Avalanche or Solana. Receiving addresses: 0xee432065474D2C852700f74e3fD81e2Bcc16a3D4 on Ethereum, Optimism, Polygon, Base, Arbitrum or Avalanche; 0xAd982CB19aCCa2923Df8F687C0614a7700255a23 on BNB Chain (USDC sent to it on the other EVM chains is also accepted during the changeover); 8fyEGM5tRjMocKQWaVXyM2XvvnTxR3sWdrYtug2zeLX4 on Solana (USDC sent to 6a1mLjefhvSJX1sEX8PTnionbE9DqoYjU6F6bNkT4Ydr is also accepted during the changeover). USDT, any other token and any other chain are refused and not credited. Non-refundable. Owner only. The first purchase registers the sending wallet to the API key; updateWallet: true replaces it. Registering or replacing the wallet takes senderSignature from the wallet that sent the payment; a payment from the registered wallet needs none. Current prices and volume discounts: https://insumermodel.com/pricing/

insumer_request_domain_verificationA

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.

insumer_verify_domainA

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.

insumer_acp_discountA

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.

insumer_ucp_discountA

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.

insumer_validate_codeA

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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 27 tools

Disambiguation3/5

Several tools compute discount eligibility or wallet facts from different angles: check_discount, verify, acp_discount, ucp_discount, wallet_trust, and attest overlap conceptually. Descriptions do distinguish signed codes, free checks, protocol wrappers, condition attestations, and trust profiles, but an agent must read carefully to choose correctly.

Naming Consistency4/5

Most tools consistently use the insumer_ prefix followed by a descriptive verb_noun or noun phrase, such as insumer_configure_tokens, insumer_list_merchants, and insumer_validate_code. There are minor deviations like insumer_credits, insumer_jwks, and insumer_setup, but the naming remains predictable overall.

Tool Count3/5

With 27 tools, the surface is heavy for an MCP server, though the domain is broad: attestations, wallet trust profiles, merchant configuration, directory listing, payments, credits, and protocol-specific discount flows. Each tool has a plausible role, but the count is at the upper edge of what an agent can navigate comfortably.

Completeness4/5

The server covers the major lifecycle areas: attestations, single and batch wallet trust, compliance templates, merchant creation/status/configuration, directory listing, domain verification, discount checking/verification/validation, and credit purchase flows. Some lifecycle gaps remain, such as merchant deletion or broader update operations, but core workflows are well covered.

Maintenance

ActivityActive
ResponsivenessSyncing