Skip to main content
Glama

insumer

by com.insumermodel
OverviewDiscussionsAdmin

insumer_attest

Verify 1-10 on-chain conditions for a wallet and return a signed yes or no for each, never the balance. Condition types: token_balance, nft_ownership, eas_attestation (raw schemaId or a compliance template such as Coinbase Verifications or Gitcoin Passport), farcaster_id (IdRegistry on Optimism), evm_view_call (a single-address-argument view function returning bool), ratio_to_amount (balance >= multiple * amount), ratio_to_supply (balance / totalSupply >= minFraction, ERC-20 only), erc8004_agent (registered ERC-8004 agent on Base), and erc7710_delegation (a signed MetaMask-framework delegation from principal to agent is currently valid on Base; spend, target and call limits are reported as declaredLimits, not simulated). Chains: EVM chains plus Solana, XRPL, Bitcoin, Tron, Stellar and Sui; Bitcoin, Tron, Stellar and Sui support token_balance only. Responses are ECDSA-signed with a kid identifying the key and carry a post-quantum companion signature; each result includes evaluatedCondition, a SHA-256 conditionHash, and the block (EVM), ledger (XRPL, Stellar) or checkpoint (Sui) it was read at. proof: 'merkle' adds EIP-1186 storage proofs on supported EVM chains. Attestations with a delegation condition expire in 5 minutes instead of 30; a failed delegation result carries failReason. Costs 1 credit (2 with proof). Current chain and check counts: https://insumermodel.com/llms.txt

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
proofNoSet 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.
formatNoSet 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.
walletNoEVM wallet address (0x...)
suiWalletNoSui 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.
conditionsYes1-10 on-chain conditions to verify
tronWalletNoTron wallet address (T-prefixed, base58). For verifying TRX or TRC20 tokens (USDT-TRC20). Use chainId 'tron'.
xrplWalletNoXRPL wallet address (r-address). For verifying XRP, trust line tokens (RLUSD, USDC), or NFTs on XRP Ledger.
solanaWalletNoSolana wallet address (base58)
bitcoinWalletNoBitcoin address (P2PKH, P2SH, bech32, or Taproot). For verifying native BTC balance. Use chainId 'bitcoin' with contractAddress 'native'.
stellarWalletNoStellar 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.
declaredLimitsNoSet 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare safety hints; the description adds substantial behavior beyond them: ECDSA signing with a kid and post-quantum companion signature, per-result evaluatedCondition/conditionHash/anchoring block, 5-minute expiry for delegation conditions vs 30 otherwise, failReason on failure, and a credit cost (2 with merkle proof). It also clarifies that declaredLimits are reported, not simulated.

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?

It is long but densely packed, and the core purpose is front-loaded ahead of the condition inventory. It loses a point because the condition-type and chain enumerations duplicate the very thorough schema rather than deferring to it.

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 a complex, 11-parameter tool with no output schema, the description covers condition semantics, chain coverage, signing/verification artifacts, expiry, cost, and failure reporting, so an agent has what it needs without the schema explaining return values.

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 all 11 parameters in depth, making 3 the baseline. The description restates condition types and chain support that the schema already carries, adding little parameter-level detail beyond what is structured.

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 first sentence states a specific verb and resource ('Verify 1-10 on-chain conditions for a wallet') plus the output shape ('signed yes or no for each, never the balance'), which differentiates it from sibling check tools. An agent immediately knows this is a multi-condition signed attestation service.

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 enumerates the condition types, supported chains, cost tiers, and when proof/format/declaredLimits apply, giving clear context for how to invoke it. However, it never names an alternative sibling (e.g. insumer_wallet_trust or insumer_batch_wallet_trust) or states when NOT to use this tool, so usage routing is left implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All insumer toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources