insumer

Wallet trust profile (signed)

insumer_wallet_trust

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 On this hosted endpoint the call is paid from a shared daily allowance, so the caller is not charged; the credit cost above applies on the caller's own API key, and each result states the price on a key and by x402 pay-per-call.

Input Schema

Name	Required	Description
`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

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026

changedInput schema / properties / proof / description

Previous 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."

Changed1 schema field changedOct 3, 2026

changedOutput 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"
+}

First observedOct 2, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false): it discloses signing semantics (conditionSetVersion must be logged, never rejected on), error semantics (503 rpc_failure means nothing was signed), refund behavior for undelivered Merkle proofs, credit pricing (3, or 6 with proof), and that the hosted endpoint draws from a shared allowance rather than charging the caller.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the body is a single dense run-on of nested parentheticals (dimension list, counts, ordering, account-row behavior, pricing, x402, llms.txt URL) that would benefit from structure. Every fact is relevant, yet the packing reduces scannability.

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 and the description still appropriately summarizes per-dimension pass/fail counts and the overall summary. Combined with error/retry semantics, cost model, and a live URL for current chain/check counts, an agent has everything needed to call and interpret this 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 100% with rich per-parameter descriptions, so the baseline is 3. The description adds real semantic detail: each optional wallet's effect (Solana/XRPL/Bitcoin/Tron add dimensions; Stellar/Sui only let existing rows evaluate) and the fixed dimension ordering, plus the two-row structure of the account dimension. It largely reinforces what the schema already says, which caps it below 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 precise verb+resource: 'Generate a signed wallet trust fact profile for an EVM wallet', then enumerates what a profile contains (presence checks across named dimensions, 155 base checks / 27 chains). This distinguishes it cleanly from the sibling insumer_batch_wallet_trust (singular vs. batch) and from insumer_attest (which is referenced for account_code proofs).

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?

States the intended use case explicitly ('Designed for AI agent-to-agent trust decisions') and gives the alternative for account proofs (the attest tool's account_code condition). It also gives operational guidance (retry on rpc_failure 503, never treat as a 'no'). It does not, however, say when to prefer this over insumer_batch_wallet_trust or the non-trust attest path for a single wallet.

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

All insumer tools Inspect

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.