Skip to main content
Glama
Sign In
InsumerAPI

InsumerAPI

by insumerapi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Add credits to the store owner key from a payment

insumer_buy_merchant_credits
Destructive

Kept for compatibility: a store has no credit balance of its own, so a payment submitted here adds regular credits to the API key that owns the store, at a flat rate (the regular credit purchase, with volume tiers, is the usual way to top…

Instructions

Kept for compatibility: a store has no credit balance of its own, so a payment submitted here adds regular credits to the API key that owns the store, at a flat rate (the regular credit purchase, with volume tiers, is the usual way to top up). Submits 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. Owner only. The first purchase registers the sending wallet to the API key; updateWallet: true replaces it. 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
idYesMerchant ID
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"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: -[
-  "id",
-  "txHash",
-  "chainId"
-]New value: +[
+  "id",
+  "txHash",
+  "chainId",
+  "amount"
+]
  2. Changed9 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 / id / maxLength
      Added value: +100
    • addedInput schema / properties / id / minLength
      Added value: +1
    • addedInput schema / properties / id / pattern
      Added value: +"^[a-zA-Z0-9_-]+$"
    • 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"New value: +"Set true to replace the registered sender wallet"
    • 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.5/5.0
Behavior5/5

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

Annotations declare destructive/openWorld/non-idempotent, and the description adds concrete behavior beyond them: it does not move funds but only submits a tx hash, payments are non-refundable, wallet registration semantics, and expected 400/403/503 outcomes with 'payment not used' guarantees. This is unusually thorough disclosure for a mutation tool.

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?

The compatibility caveat is front-loaded, good. But the body is a dense wall that repeats signature-text and chain details already present in the schema, and embeds long address lists mid-paragraph. Much earns its place, but the repetition and density cost it.

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?

With an output schema present and rich annotations, the description covers everything an agent needs: purpose, payment rails, addresses, wallet registration, signature requirements, and failure modes. 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 baseline is 3, but the description adds value beyond the schema: the receiving addresses per chain, the non-refundable consequence of an amount, and error semantics tied to senderSignature. Some signature text is duplicated from the schema, which caps it below 5.

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 description states a specific verb+resource: submitting a USDC payment tx hash to add credits to the API key that owns a store, and explicitly contrasts this with the regular credit purchase with volume tiers. An agent can distinguish it from insumer_buy_credits and insumer_confirm_payment without opening schemas. The 'kept for compatibility' framing also disambiguates legacy use.

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?

It names the alternative ('the regular credit purchase, with volume tiers, is the usual way to top up') and the condition that selects this legacy path, plus explicit constraints (USDC only, listed chains, owner only, non-refundable). It stops short of naming insumer_buy_credits directly or spelling out exclusions like 'do not use for fresh onboarding', keeping it at 4.

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