InsumerAPI

Overview Schema Source Related Servers Discussions Admin

Add credits from a payment

insumer_buy_credits

Destructive

Add verification credits to your API key by submitting a crypto payment transaction hash. Supports USDC, USDT, BTC, and USDT-TRC20; no funds are moved.

Instructions

Add verification credits to the current API key against a USDC, USDT, BTC, or USDT-TRC20 payment the caller has already sent. This tool does not move funds: it submits the transaction hash. USDC/USDT on EVM and Solana (auto-detected), USDT-TRC20 on Tron, BTC on Bitcoin (converted at market rate, 1 confirmation required). Crypto sent on unsupported chains cannot be recovered. Non-refundable. The first purchase registers the sender wallet to the API key; later purchases must come from the same sender, and updateWallet: true replaces the registered wallet. Current prices and volume discounts: https://insumermodel.com/pricing/

Input Schema

TableJSON Schema

Name	Required	Description
`amount`	No	Stablecoin amount sent (minimum 5). Not required for BTC.
`txHash`	Yes	Transaction hash proving payment
`chainId`	Yes	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.
`updateWallet`	No	Set true to replace the registered sender wallet with this transaction's sender

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.

Changed6 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})$"

changedInput schema / properties / updateWallet / description

Previous value: -"Set true to update the registered sender wallet to this transaction's sender"New value: +"Set true to replace the registered sender wallet with this transaction's sender"

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?

Annotations cover safety (destructiveHint, idempotentHint=false, openWorldHint), but the description adds substantial context beyond them: it does not move funds, unsupported chains are unrecoverable, purchases are non-refundable, the first purchase registers the sender wallet, later purchases must use the same sender, and updateWallet replaces it. These are material behaviors an agent cannot derive from structured fields.

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?

Dense but front-loaded, and every clause carries non-obvious information (chain support, conversion, wallet rules, irreversibility). It is on the longer side for a description, but no sentence is padding.

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 so return values need no explanation, and the description covers the mechanics, supported chains, irreversibility, wallet registration, and a pricing pointer. An agent has everything needed to invoke it 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 already 100%, so the schema documents amount, txHash, chainId, and updateWallet. The description still adds useful meaning beyond it: EVM/Solana auto-detect USDC vs USDT, BTC is converted at market rate with 1 confirmation, and the wallet-registration/updateWallet semantics.

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+resource ('Add verification credits to the current API key') and immediately narrows the input to a tx hash for a payment already sent. This clearly distinguishes it from siblings like insumer_buy_key, insumer_buy_merchant_credits, and insumer_confirm_payment.

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 establishes the precondition clearly ('a payment the caller has already sent', 'it submits the transaction hash'), which tells the agent this is a post-payment submission step. It does not, however, explicitly name the related sibling tool (e.g. insumer_confirm_payment or insumer_buy_key) as an alternative, so routing is inferred rather than stated.

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