InsumerAPI

Overview Schema Source Related Servers Discussions Admin

Batch wallet trust profiles (signed)

insumer_batch_wallet_trust

Instructions

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.

Input Schema

TableJSON Schema

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

TableJSON 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 changedv1.17.2Oct 13, 2026

addedInput schema / properties / detail

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

Changed11 schema fields changedv1.16.0Oct 4, 2026

changedInput schema / properties / wallets / items / properties / bitcoinWallet / description

Previous value: -"Bitcoin address. Adds Bitcoin Holdings dimension."New value: +"Bitcoin address. Adds the Bitcoin dimension."

addedInput schema / properties / wallets / items / properties / bitcoinWallet / pattern

Added value: +"^(?:[13][1-9A-HJ-NP-Za-km-z]{25,34}|(?:bc1|BC1)[02-9ac-hj-np-zAC-HJ-NP-Z]{11,87})$"

changedInput schema / properties / wallets / items / properties / solanaWallet / description

Previous value: -"Solana wallet address (base58). Adds USDC on Solana check."New value: +"Solana wallet address (base58). Adds the Solana dimension."

addedInput schema / properties / wallets / items / properties / solanaWallet / pattern
```
Added value: +"^[1-9A-HJ-NP-Za-km-z]{32,44}$"
```

addedInput schema / properties / wallets / items / properties / stellarWallet

Added value: +{
+  "description": "Stellar wallet address (G-prefixed). Lets the rows on Stellar evaluate; adds no dimension.",
+  "pattern": "^G[A-Z2-7]{55}$",
+  "type": "string"
+}

addedInput schema / properties / wallets / items / properties / suiWallet

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

addedInput schema / properties / wallets / items / properties / tronWallet

Added value: +{
+  "description": "Tron wallet address (T-prefixed). Adds the Tron dimension.",
+  "pattern": "^T[1-9A-HJ-NP-Za-km-z]{33}$",
+  "type": "string"
+}

addedInput schema / properties / wallets / items / properties / wallet / pattern
```
Added value: +"^0x[0-9a-fA-F]{40}$"
```

changedInput schema / properties / wallets / items / properties / xrplWallet / description

Previous value: -"XRPL wallet address (r-address). Adds RLUSD and USDC on XRPL checks."New value: +"XRPL wallet address (r-address). Adds the XRPL dimension."

addedInput schema / properties / wallets / items / properties / xrplWallet / pattern
```
Added value: +"^r[1-9A-HJ-NP-Za-km-z]{24,34}$"
```

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

Addedv0.1.0Apr 28, 2026

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.