Skip to main content
Glama
Sign In
Stables MCP Server

Stables MCP Server

Official
by stables-money
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create balance wallet

create_balance_wallet
Destructive

Establish a deposit wallet for specific networks like Ethereum or Solana to fund your account. This asynchronous process confirms the wallet is ready for incoming transfers.

Instructions

Create the deposit wallet that tops up your balance on a network. Creation is asynchronous: the first answer is 'creating'; poll get_balance_wallet until it is 'active'. Safe to call again while creation is in flight.

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": {
      "network": "<network>"
    },
    "name": "create_balance_wallet"
  }
}

Input Schema

NameRequiredDescriptionDefault
networkYesNetwork for the wallet

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.6.11
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv2.4.0

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations it discloses the genuinely non-obvious behavior: creation is asynchronous, the first response status is 'creating', and completion must be confirmed via get_balance_wallet. The retry claim is scoped to the in-flight window, which sits slightly uneasily with idempotentHint=false, but it clarifies rather than contradicts; it omits permissions, cost, and what happens if a wallet already exists.

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?

Three short sentences, front-loaded with the action and function, then the async contract, then the retry condition. No filler and nothing repeated from the schema.

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

Completeness4/5

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

For an async, side-effecting create with no output schema, the description supplies the state machine and follow-up call an agent needs to complete the workflow. Minor gaps remain around the destructiveHint implication (irreversibility, one-wallet-per-network limits) and error conditions.

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

Parameters3/5

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

With a single parameter at 100% schema description coverage and an enum of four networks, the schema already carries the semantics. 'On a network' in the description adds no format or constraint detail beyond what the enum provides.

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 gives a specific verb and resource ('Create the deposit wallet') plus its function ('tops up your balance on a network'), which separates it cleanly from the read-side sibling get_balance_wallet and from the other create_* tools. An agent knows immediately what is produced and why.

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 explicitly routes the agent to the follow-up tool ('poll get_balance_wallet until it is active') and states that re-calling during in-flight creation is safe, which is exactly the guidance needed for an async create. It does not say when NOT to call it (e.g., whether a wallet may already exist for that network), so it falls short of full when/when-not coverage.

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