VoidMob MCP

Official

Overview Schema Source Related Servers Discussions Admin

Add funds with a crypto deposit

create_deposit

Adds funds to a prepaid balance by generating a crypto deposit with the exact amount, network, address, and deadline so users can pay from a wallet.

Instructions

Create a deposit to add funds to the prepaid balance with crypto. Returns the exact amount to send, the network, the address and the deadline, plus the payment window in the VoidMob dashboard where the user can check the address. Payment comes from a crypto wallet: the user's, or their own automation's. The balance goes up once the payment confirms, and any extra is credited too. It spends nothing, so it needs no purchase approval, but ask the user which coin and how much unless they said. Keep at most one open deposit: check get_deposit first and reuse one that still takes payments. After a purchase is refused for a low balance, offer a deposit rather than creating one.

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": {
      "coin": "<coin>",
      "amount_cents": "<amount_cents>"
    },
    "name": "create_deposit"
  }
}

Input Schema

Name	Required	Description	Default
`coin`	Yes	Coin id from get_deposit (e.g. 'ltc', 'btc', 'usdt_trc20')
`amount_cents`	Yes	Amount to add in US cents (2000 = $20.00). Each coin has a minimum (get_deposit lists them).

Output Schema

Name	Required	Description	Default
`deposit`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.0Nov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false): it discloses what the call returns (amount, network, address, deadline, dashboard payment window), when the balance actually increases (on confirmation, with overpayment credited), and that no purchase approval is needed because nothing is spent. The non-idempotent 'keep at most one open deposit' rule is exactly the kind of operational caveat annotations cannot express.

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?

Front-loaded with the outcome and the return shape, then rules, then edge-case guidance. Dense but each sentence carries information; the long compound final sentences could be split for faster scanning, but nothing 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?

Even though an output schema exists, the description still orients the agent on the return shape and the confirmation semantics. Combined with the full param coverage and clear safety framing, there is no material gap for a two-parameter write tool that creates a payment address.

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 coin and amount_cents are already fully documented, including the get_deposit minimum lookup. The description adds a little useful meaning by instructing the agent to confirm coin and amount with the user before calling, which shapes how the parameters should be sourced.

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 and resource ('Create a deposit to add funds to the prepaid balance with crypto') and implicitly distinguishes it from the read-only sibling get_deposit, which it names explicitly later. An agent knows exactly what this tool produces without opening the schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use and when-not-to-use rules: ask the user for coin and amount unless already stated, check get_deposit first and reuse an open deposit that still takes payments, and after a refused purchase offer a deposit rather than creating one. It names the alternative tool and the condition selecting it, plus a hard constraint of at most one open deposit.

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