Skip to main content
Glama
Sign In
InsumerAPI

InsumerAPI

by insumerapi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Add credits from a payment

insumer_buy_credits
Destructive

Add verification credits to the current API key against a USDC payment the caller has already sent. This tool does not move funds: it submits the transaction hash.

Instructions

Add verification credits to the current API key against a USDC payment the caller has already sent. This tool does not move funds: it submits the transaction hash. 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. Non-refundable. The first purchase registers the sending wallet to the API key; later purchases must come from the same wallet, and updateWallet: true replaces the registered wallet. Registering or replacing the wallet takes senderSignature from the wallet that sent the payment; a payment from the registered wallet needs none. Current prices and volume discounts: https://insumermodel.com/pricing/

Input Schema

NameRequiredDescriptionDefault
amountYesUSDC amount sent (minimum 5).
txHashYesTransaction hash proving payment
chainIdYesChain 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.
updateWalletNoSet true to replace the registered wallet with this transaction's sender. Takes senderSignature from the new wallet.
senderSignatureNoRequired when the key has no registered wallet yet, or with updateWallet: true when the payment comes from a different wallet; not needed for a payment from the registered wallet. 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: credit 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

NameRequiredDescriptionDefault
okNotrue when the API call succeeded
dataNoThe endpoint's payload: a signed attestation, trust profile, discount, merchant or token records
keysNoJWKS entries (insumer_jwks)
metaNoResponse metadata such as version and timestamp
errorNoError details when ok is false
itemsNoThe result when the endpoint returns a JSON array
messageNoA plain-text result (insumer_setup), or a message from the API

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.23.0
    • changedInput schema / properties / amount / description
      Previous value: -"Stablecoin amount sent (minimum 5). Not required for BTC."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 when the key has no registered wallet yet, or with updateWallet: true when the payment comes from a different wallet; not needed for a payment from the registered wallet. 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: credit 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 / properties / updateWallet / description
      Previous value: -"Set true to replace the registered sender wallet with this transaction's sender"New value: +"Set true to replace the registered wallet with this transaction's sender. Takes senderSignature from the new wallet."
    • changedInput schema / required
      Previous value: -[
-  "txHash",
-  "chainId"
-]New value: +[
+  "txHash",
+  "chainId",
+  "amount"
+]
  2. Changed6 schema fields changedv1.16.0
    • 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"
+}
  3. Addedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, idempotentHint=false) by disclosing non-refundability, which tokens and chains are refused, the wallet-binding side effect that persists across calls, and concrete error semantics (400 returns the exact signing text, 403 means wrong signer, 503 is retryable). The 'does not move funds' clarification usefully qualifies the destructive hint.

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?

Purpose and the crucial 'does not move funds' caveat are front-loaded, and every block (addresses, refused tokens, wallet binding, signatures) is operationally necessary. Minor waste: the chain name list duplicates the chainId enum in the schema.

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 payment-crediting mutation with 5 params, an output schema, and no refund path, the description covers everything an agent needs: which chains/tokens are accepted, exact receiving addresses, signature requirements per scenario, error recovery, and where to find current pricing.

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%, yet the description adds real meaning: the wallet-to-API-key binding rules that govern when senderSignature is needed, and the chain-to-receiving-address mapping that the schema does not contain. It does not restate the signing text or amount minimum, which the schema already documents.

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?

States a specific verb and resource: 'Add verification credits to the current API key against a USDC payment'. The 'current API key' scoping implicitly separates it from the sibling insumer_buy_merchant_credits, but no sibling is named explicitly, so an agent must infer the split.

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?

Prerequisites are clear: the caller must have already sent USDC, and the tool 'does not move funds: it submits the transaction hash'. Wallet-registration conditions (first purchase registers, later purchases must match, updateWallet replaces) are spelled out. It stops short of naming alternatives such as insumer_confirm_payment or insumer_buy_key when the payment flow is different.

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

Deploy Server

Other Tools