insumer

Batch wallet trust profiles (signed)

insumer_batch_wallet_trust

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

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

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

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?

With annotations present the bar is lower, yet the description still discloses cost (3 credits per successful wallet, 6 with merkle, x402 covers all wallets), partial-success semantics, the fact that failed wallets yield no signed profile and must not be read as 'no', that profiles cannot be re-fetched (consistent with idempotentHint=false), the response size, and the summary-vs-structuredContent split. This is unusually rich 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.

Conciseness3/5

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

Front-loaded correctly with purpose and speed benefit, but the body is a dense block that restates the detail parameter and the credit/x402 pricing twice, and mixes pricing, dimension ordering, retry policy, and response format without structure. Every fact is useful, but a scanner cannot easily locate a specific concern.

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 3-parameter tool with full schema coverage, an output schema, and annotations, the description covers everything an agent needs to call it correctly: cost model, partial-failure handling, dimension ordering, response size, and the non-repeatability of signed profiles.

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, and the description goes beyond the schema by explaining that Solana/XRPL/Bitcoin/Tron wallets each switch on an extra dimension and that dimensions arrive in a fixed, identical order for every wallet in the batch. The credit implication of proof='merkle' (6 vs 3) is also stated, which the schema does not 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?

The opening sentence gives a precise verb, resource, and scope: 'Generate wallet trust fact profiles for up to 10 wallets in a single request.' The batch framing ('Faster than sequential calls') cleanly separates it from the single-wallet sibling insumer_wallet_trust without the agent needing to open either schema.

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 conditional guidance: set detail='full' only on the call that needs it, add proof='merkle' when Merkle storage proofs are required, and retry only the wallets that came back as error entries. It does not explicitly name insumer_wallet_trust as the single-wallet alternative, so the 'when not to use this' side is left to inference.

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.