InsumerAPI

Overview Schema Source Related Servers Discussions Admin

Register a paid API key

insumer_buy_key

Instructions

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/

Input Schema

Name	Required	Description
`amount`	Yes	USDC amount sent (minimum 5).
`txHash`	Yes	Transaction hash proving payment
`appName`	Yes	Name for the API key (e.g. your agent or app name)
`chainId`	Yes	Chain where the USDC was sent: Ethereum (1), Optimism (10), BNB Chain (56), Polygon (137), Base (8453), Arbitrum (42161), Avalanche (43114), or 'solana'. Purchases are paid in USDC only.
`senderSignature`	Yes	Required. The wallet that sent the payment signs this exact text, five lines joined by \n with no trailing newline: "api.insumermodel.com", "Confirm the wallet that sent this payment.", "Purpose: key purchase", "Chain: eip155:<chainId>" (or "Chain: solana"), "Transaction: <transaction hash>" (EVM as 0x plus lowercase hex, Solana as given). When the signature is required, a call without it returns the exact text in a 400 and the payment is not used. EVM: personal_sign (EIP-191), 0x hex; a smart wallet is checked with ERC-1271. Solana: signMessage (ed25519), base58 or base64. A 403 means the signature is not from the wallet that sent the payment; a 503 means a smart-wallet check could not complete and the payment was not used, so retry.

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.

Changed5 schema fields changedv1.23.0Oct 22, 2026

changedInput schema / properties / amount / description

Previous value: -"Stablecoin amount sent (minimum 5). Not required for BTC: USD value derived from on-chain amount at market rate."New value: +"USDC amount sent (minimum 5)."

changedInput schema / properties / chainId / anyOf

Previous value: -[
-  {
-    "enum": [
-      "1",
-      "8453",
-      "137",
-      "42161",
-      "10",
-      "56",
-      "43114"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "integer"
-  },
-  {
-    "const": "solana",
-    "type": "string"
-  },
-  {
-    "const": "bitcoin",
-    "type": "string"
-  },
-  {
-    "const": "tron",
-    "type": "string"
-  }
-]New value: +[
+  {
+    "enum": [
+      "1",
+      "8453",
+      "137",
+      "42161",
+      "10",
+      "56",
+      "43114"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "const": "solana",
+    "type": "string"
+  }
+]

changedInput schema / properties / chainId / description

Previous value: -"Payment chain: 1, 8453, 137, 42161, 10, 56, 43114, 'solana', 'bitcoin', or 'tron'. EVM/Solana accept USDC and USDT (auto-detected). Bitcoin accepts BTC (converted to USD at market rate). Tron accepts USDT-TRC20."New value: +"Chain where the USDC was sent: Ethereum (1), Optimism (10), BNB Chain (56), Polygon (137), Base (8453), Arbitrum (42161), Avalanche (43114), or 'solana'. Purchases are paid in USDC only."

addedInput schema / properties / senderSignature

Added value: +{
+  "description": "Required. The wallet that sent the payment signs this exact text, five lines joined by \\n with no trailing newline: \"api.insumermodel.com\", \"Confirm the wallet that sent this payment.\", \"Purpose: key purchase\", \"Chain: eip155:<chainId>\" (or \"Chain: solana\"), \"Transaction: <transaction hash>\" (EVM as 0x plus lowercase hex, Solana as given). When the signature is required, a call without it returns the exact text in a 400 and the payment is not used. EVM: personal_sign (EIP-191), 0x hex; a smart wallet is checked with ERC-1271. Solana: signMessage (ed25519), base58 or base64. A 403 means the signature is not from the wallet that sent the payment; a 503 means a smart-wallet check could not complete and the payment was not used, so retry.",
+  "maxLength": 16384,
+  "minLength": 1,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "txHash",
-  "chainId",
-  "appName"
-]New value: +[
+  "txHash",
+  "chainId",
+  "amount",
+  "appName",
+  "senderSignature"
+]

Changed1 schema field changedv1.17.2Oct 13, 2026

changedInput schema / properties / amount / description

Previous value: -"Stablecoin amount sent (minimum 5). Not required for BTC — USD value derived from on-chain amount at market rate."New value: +"Stablecoin amount sent (minimum 5). Not required for BTC: USD value derived from on-chain amount at market rate."

Changed5 schema fields changedv1.16.0Oct 4, 2026

changedInput schema / properties / chainId / anyOf

Previous value: -[
-  {
-    "enum": [
-      "1",
-      "8453",
-      "137",
-      "42161",
-      "10",
-      "56",
-      "43114"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "integer"
-  },
-  {
-    "const": "solana",
-    "type": "string"
-  },
-  {
-    "const": "bitcoin",
-    "type": "string"
-  }
-]New value: +[
+  {
+    "enum": [
+      "1",
+      "8453",
+      "137",
+      "42161",
+      "10",
+      "56",
+      "43114"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "const": "solana",
+    "type": "string"
+  },
+  {
+    "const": "bitcoin",
+    "type": "string"
+  },
+  {
+    "const": "tron",
+    "type": "string"
+  }
+]

changedInput schema / properties / chainId / description

Previous value: -"Payment chain: 1, 8453, 137, 42161, 10, 56, 43114, 'solana', or 'bitcoin'. EVM/Solana accept USDC and USDT (auto-detected). Bitcoin accepts BTC (converted to USD at market rate)."New value: +"Payment chain: 1, 8453, 137, 42161, 10, 56, 43114, 'solana', 'bitcoin', or 'tron'. EVM/Solana accept USDC and USDT (auto-detected). Bitcoin accepts BTC (converted to USD at market rate). Tron accepts USDT-TRC20."

addedInput schema / properties / txHash / maxLength
```
Added value: +100
```

addedInput schema / properties / txHash / pattern

Added value: +"^(?:0x[0-9a-fA-F]{64}|[0-9a-fA-F]{64}|[1-9A-HJ-NP-Za-km-z]{43,90})$"

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.3/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint false, idempotent false, openWorldHint true), the description discloses that no auth is required, that the tool does not move funds, that payments are non-refundable, that one key exists per wallet, that the sending wallet becomes the key's wallet, and it defines the 400/403/503 outcomes in the schema-level signature text. This is unusually rich operational context for a mutating tool.

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?

Key facts (no auth, no fund movement, what to submit) are front-loaded in the first two sentences, and every later sentence carries an operational constraint. The single dense paragraph with nested parenthetical changeover addresses is harder to scan than a bulleted payment-address list would be, but little is genuinely wasted.

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 five-parameter, no-auth, payment-coupled mutation with an output schema already present, the description covers auth, payment rails, accepted chains, per-chain receiving addresses, non-refundability, the one-key-per-wallet rule, and a pricing link. Nothing an agent needs in order to call it correctly is missing.

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 genuinely adds meaning: it enumerates the accepted chains and receiving addresses per chain, constrains the token to USDC, and explains that the sending wallet (not an arbitrary signer) becomes the key's wallet. It does not restate the amount minimum or the signature text format, which the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 — register an API key against an already-sent USDC payment — and immediately bounds it with 'no auth required, no email' plus 'does not move funds: it submits the transaction hash and a signature.' It is easy to distinguish from siblings like insumer_buy_credits or insumer_confirm_payment, though no sibling is named explicitly.

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 makes the precondition explicit — the caller must have already sent the USDC and must therefore call this only after payment — and it supplies the when-not rule that an existing key is topped up via a credit purchase instead. It also states that USDT, other tokens and other chains are refused and not credited. The alternative tool (insumer_buy_credits) is described by behavior rather than by name, so routing is possible but requires inference.

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