Skip to main content
Glama
Sign In
Stables MCP Server

Stables MCP Server

Official
by stables-money
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Simulate transfer deposit (sandbox)

simulate_transfer_deposit
Destructive

Simulate a customer crypto deposit in sandbox to advance an off-ramp transfer to payout without an on-chain payment; fails in production.

Instructions

SANDBOX ONLY. Simulate the customer sending the crypto an off-ramp transfer is waiting on, so the transfer can progress to payout without an on-chain payment. Fails on production.

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": {
      "transferId": "<transferId>"
    },
    "name": "simulate_transfer_deposit"
  }
}

Input Schema

NameRequiredDescriptionDefault
transferIdYesThe transfer awaiting funds

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/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=false; the description adds the non-obvious environmental behavior (silently fails on production) and the actual effect (transfer advances to payout without real funds). It does not say what happens on repeat calls or whether the simulated deposit is reversible, which the non-idempotent annotation hints at but doesn't explain.

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?

Two sentences, zero waste, and the most consequential constraint (SANDBOX ONLY) is front-loaded in caps before any other detail.

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 a single-parameter, no-output-schema tool whose annotations already carry the safety profile, the description supplies the environment limit and the intended outcome. Only repeat-call behavior and post-payout semantics are left unstated, which is minor.

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?

Schema coverage is 100% and there is only one parameter, so the schema already defines transferId as 'The transfer awaiting funds'. The description restates that constraint in prose ('the crypto an off-ramp transfer is waiting on') without adding format or lookup guidance, so baseline 3 applies.

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?

States a specific verb ('Simulate') and resource ('the crypto an off-ramp transfer is waiting on'), plus the effect ('transfer can progress to payout'). It is clear what the tool does, though it never names or contrasts with the sibling simulate_route_deposit, leaving that differentiation to inference.

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?

The 'SANDBOX ONLY ... Fails on production' line gives a clear environment condition for use, which is the key usage constraint here. There is no explicit statement of when to prefer this over waiting for a real on-chain deposit or using simulate_route_deposit, but the context is unambiguous.

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