Skip to main content
Glama

Kairos Signal — verifiable DePIN data API

Add credits (card checkout link or USDC quote)

topup_credits

Add credits. Card (one call): {"method": "stripe", "amount": N} where N is $20 or $99 — returns a Stripe checkout_url already bound to your api_key, and credits post automatically once Stripe confirms payment at $1 = 1 credit. No human step and no wallet needed. USDC on Base, two modes. micro_decimal, no wallet signature: {"method": "usdc", "mode": "micro_decimal", "amount": N} with N whole USDC from 1 to 999,999 returns a unique amount with a 6-decimal suffix and an expires_at; a finalized Base transfer of EXACTLY that amount, from any sender including an exchange, before expires_at credits your account (1 USDC = 1 credit); a different amount does not credit your account. verified_wallet (the default when mode is omitted): verify your sender first via POST /v1/credits/crypto/challenge and /verify with X-API-Key, sign the returned challenge with your own EOA, then pass the verified from_address; only a transfer FROM that wallet is credited. In every USDC mode send only after a successful quote; credit requires finalized Base evidence. Instructions: https://kairossignal.com/docs/crypto.html

Input Schema

NameRequiredDescriptionDefault
modeNoUSDC only. micro_decimal: no wallet signature; the quote is a unique amount to send exactly, from any sender. verified_wallet (default when omitted): requires from_address verified through the wallet challenge flow. Ignored for stripe.
amountYesstripe: Amount in USD to add. Fixed packs only: 20 or 99. Any other value returns the available packs instead of a link. USDC micro_decimal: whole USDC, 1 to 999999. USDC verified_wallet: the USDC amount to quote (GET /v1/credits/crypto states the accepted range).
methodYesPayment method
api_keyYesYour API key
tx_hashNoLegacy optional field; a transaction hash does not replace from_address or verify payment.
from_addressNoRequired for USDC verified_wallet mode (the default): your EOA address already verified to this API account through the wallet challenge flow. Not used by micro_decimal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / allOf
      Previous value: -[
      -  {
      -    "if": {
      -      "properties": {
      -        "method": {
      -          "const": "usdc"
      -        }
      -      },
      -      "required": [
      -        "method"
      -      ]
      -    },
      -    "then": {
      -      "required": [
      -        "from_address"
      -      ]
      -    }
      -  }
      -]New value: +[
      +  {
      +    "if": {
      +      "properties": {
      +        "method": {
      +          "const": "stripe"
      +        }
      +      },
      +      "required": [
      +        "method"
      +      ]
      +    },
      +    "then": {
      +      "properties": {
      +        "amount": {
      +          "enum": [
      +            20,
      +            99
      +          ]
      +        }
      +      }
      +    }
      +  },
      +  {
      +    "if": {
      +      "properties": {
      +        "method": {
      +          "const": "usdc"
      +        },
      +        "mode": {
      +          "const": "micro_decimal"
      +        }
      +      },
      +      "required": [
      +        "method",
      +        "mode"
      +      ]
      +    },
      +    "then": {
      +      "properties": {
      +        "amount": {
      +          "maximum": 999999,
      +          "minimum": 1,
      +          "type": "integer"
      +        }
      +      }
      +    }
      +  },
      +  {
      +    "if": {
      +      "not": {
      +        "properties": {
      +          "mode": {
      +            "const": "micro_decimal"
      +          }
      +        },
      +        "required": [
      +          "mode"
      +        ]
      +      },
      +      "properties": {
      +        "method": {
      +          "const": "usdc"
      +        }
      +      },
      +      "required": [
      +        "method"
      +      ]
      +    },
      +    "then": {
      +      "required": [
      +        "from_address"
      +      ]
      +    }
      +  }
      +]
    • changedInput schema / properties / amount / description
      Previous value: -"Amount in USD to add. Fixed packs only: 20 or 99. Any other value returns the available packs instead of a link."New value: +"stripe: Amount in USD to add. Fixed packs only: 20 or 99. Any other value returns the available packs instead of a link. USDC micro_decimal: whole USDC, 1 to 999999. USDC verified_wallet: the USDC amount to quote (GET /v1/credits/crypto states the accepted range)."
    • removedInput schema / properties / amount / enum
      Removed value: -[
      -  20,
      -  99
      -]
    • changedInput schema / properties / from_address / description
      Previous value: -"Required for USDC: your EOA address already verified to this API account through the wallet challenge flow."New value: +"Required for USDC verified_wallet mode (the default): your EOA address already verified to this API account through the wallet challenge flow. Not used by micro_decimal."
    • addedInput schema / properties / mode
      Added value: +{
      +  "description": "USDC only. micro_decimal: no wallet signature; the quote is a unique amount to send exactly, from any sender. verified_wallet (default when omitted): requires from_address verified through the wallet challenge flow. Ignored for stripe.",
      +  "enum": [
      +    "verified_wallet",
      +    "micro_decimal"
      +  ],
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / amount / description
      Previous value: -"Amount in USD to add"New value: +"Amount in USD to add. Fixed packs only: 20 or 99. Any other value returns the available packs instead of a link."
    • addedInput schema / properties / amount / enum
      Added value: +[
      +  20,
      +  99
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / from_address / description
      Previous value: -"Required for USDC: the exact EVM wallet address you will send from."New value: +"Required for USDC: your EOA address already verified to this API account through the wallet challenge flow."
  4. Changed3 schema fields changed
    • addedInput schema / allOf
      Added value: +[
      +  {
      +    "if": {
      +      "properties": {
      +        "method": {
      +          "const": "usdc"
      +        }
      +      },
      +      "required": [
      +        "method"
      +      ]
      +    },
      +    "then": {
      +      "required": [
      +        "from_address"
      +      ]
      +    }
      +  }
      +]
    • addedInput schema / properties / from_address
      Added value: +{
      +  "description": "Required for USDC: the exact EVM wallet address you will send from.",
      +  "pattern": "^0x[0-9a-fA-F]{40}$",
      +  "type": "string"
      +}
    • changedInput schema / properties / tx_hash / description
      Previous value: -"USDC transaction hash (for crypto payments)"New value: +"Legacy optional field; a transaction hash does not replace from_address or verify payment."
  5. First observed

TDQS

A4.1/5.0
Behavior5/5

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

The description provides rich behavioral detail beyond annotations: it explains that the stripe checkout_url is bound to the api_key and credits post automatically, that micro_decimal returns a unique amount with an expiry and requires exact matching, and that verified_wallet requires prior wallet verification. These details substantially augment the annotations.

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?

The description is front-loaded with 'Add credits' and then logically organized by payment method. It is somewhat lengthy due to the complexity, but every sentence contributes necessary information. Slight redundancy with schema descriptions prevents a 5.

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?

Given the tool's complexity (two distinct payment flows with multiple modes), the description covers all essential aspects: how to initiate each flow, what to expect in return, and the conditions for credit posting. The included documentation link further ensures completeness.

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 description coverage is 100%, so all parameters are documented in the schema. The description adds value by explaining concrete edge cases (e.g., a different amount does not credit your account) and providing example payloads, going beyond the schema's parameter definitions.

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 description opens with 'Add credits' and clearly details the two payment methods (card and USDC). It distinguishes the two paths internally but does not explicitly compare to sibling tools like purchase_data, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to call each method and mode but does not state when to use this tool versus alternatives or when to prefer stripe over USDC. Usage is implied by the payment method descriptions, leaving gaps in strategic guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.