Skip to main content
Glama
Sign In
btcmatic-mcp-server

btcmatic-mcp-server

Official
by btcmatic-com
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Claim a paid top-up as a bearer token

btcmatic_topup_claim

Prove a top-up payment by submitting its payment hash and preimage to claim the prepaid token exactly once, then restart the server with that token to enable automatic balance debits for paid tools.

Instructions

Proves the top-up payment with its preimage and receives the prepaid token EXACTLY ONCE. Store it and restart this server with BTCMATIC_AGENT_TOKEN= so every paid tool debits the balance automatically.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "payment_hash": "<payment_hash>",
      "preimage": "<preimage>"
    },
    "name": "btcmatic_topup_claim"
  }
}

Input Schema

NameRequiredDescriptionDefault
preimageYes
payment_hashYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

The description discloses the exactly-once guarantee, the side effect of resuming/restarting the server, and the environment variable requirement. Without readOnly/destructive annotations, the description itself bears this weight, but it does not mention permissions, rollback, or other behavioral consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It consists of two dense but useful sentences and a collateral instruction. Every word contributes; no fluff. Well formatted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, no description of a return value, and not much context for the cryptographic token value or exceptions. Task states input requirements but not output. It also relies on an operational detail (surcharge) but not the actual meaning of a state restoration.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has parameters (preimage, payment_hash) with regex patterns but no descriptions. The description only reluctantly refers to them as 'payment preimage' and 'payment hash', adding little value beyond the schema. There are no defaults or types. With <50% schema coverage, information is scarce.

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 uses a specific verb ('proves'), identifies the resource (a paid top-up as a bearer token), and details unique behavior: the prepayment is proven via its hahs preimage, and the token is received exactly once. The wording 'EXACTLY ONCE' and 'store it' distinguishes this claim operation from sibling tools, but it does not explicitly name itself a top-up claim operation or contrast with alternatives.

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?

It establishes usage context by explaining that claiming the token precedes restarting the server with the agent token so that all paid tools automatically debit the balance. It does not, however, explicitly state when to use this instead of a sibling tool or include exclusion criteria.

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