Skip to main content
Glama
Sign In
Stables MCP Server

Stables MCP Server

Official
by stables-money
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Validate payment method

validate_payment_method
Read-onlyIdempotent

Check bank payout details against corridor rules before creating a transfer to confirm required fields and avoid rejected transfers that waste a short-lived quote.

Instructions

Check bank payout details against the corridor's rules without creating anything. Use it before create_transfer to find out which fields a currency needs (beneficiary address, date of birth, bank codes), instead of spending a short-lived quote on a rejected transfer.

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": "validate_payment_method"
  }
}

Input Schema

NameRequiredDescriptionDefault
ibanNoIBAN (EU/international)
cnapsNoCNAPS (China)
payIdNoPayID alias (AUD only). Requires payIdType
bicCodeNoBIC (EUR/GBP international)
bsbCodeNoBSB code (Australia)
networkYesPayout network: local bank rails, SWIFT, or PayID (AUD)
quoteIdNoValidate against this quote's corridor
bankCodeNoBank code / institution number (CAD)
bankNameNoName of the destination bank
ifscCodeNoIFSC code (India)
sortCodeNoSort code (UK)
payIdTypeNoPayID alias type. Required when payId is given
swiftCodeNoSWIFT code
branchCodeNoBranch code / transit number (CAD)
accountTypeNoAccount type. Required for CAD and USD bank payouts
addressCityNoBeneficiary city
bankCountryNoBank country, ISO 2-letter (e.g. 'AU', 'US')
dateOfBirthNoBeneficiary date of birth, YYYY-MM-DD. Required when recipientType is individual for AED, CAD, EUR, GBP, MXN, USD
addressStateNoBeneficiary state or region
bankCurrencyNoPayout currency, ISO 3-letter (e.g. 'EUR')
accountNumberNoBank account number, if not using IBAN
addressStreetNoBeneficiary street address
recipientTypeNoBeneficiary type. Required for AED, CAD, EUR, GBP, MXN, USD
routingNumberNoABA routing number (US)
addressCountryNoBeneficiary country, ISO 2-letter. The complete address is required for AED, CAD, EUR, GBP, MXN, USD
accountHolderNameNoAccount holder's full name, or the company name when recipientType is business
addressPostalCodeNoBeneficiary postal code

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

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

Annotations already declare readOnly, idempotent, non-destructive, and the description reinforces rather than contradicts that with 'without creating anything'. It also discloses a non-obvious behavior — the call is a discovery mechanism for corridor-specific required fields — but never says whether failures come back as errors or as a structured validation result, which an agent needs to interpret the outcome.

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 with no filler, and the read-only constraint is front-loaded before the usage advice. Every clause carries information an agent would otherwise have to infer.

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 27-parameter tool the description does the important work: purpose, ordering relative to create_transfer, and the corridor-dependent field discovery. With no output schema, though, it should say what a call actually returns (valid/invalid, list of missing fields, error codes) so the agent knows how to act on the result.

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 the baseline is 3, and the description earns a bump by naming the field families that vary per corridor (beneficiary address, date of birth, bank codes) so the agent knows what to expect across 27 params. It stops short of explaining how the corridor itself is determined (quoteId versus bankCurrency/bankCountry), which is the highest-leverage parameter decision here.

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 ('Check bank payout details against the corridor's rules') and immediately bounds the scope with 'without creating anything'. That framing distinguishes it cleanly from create_transfer and create_beneficiary without needing either schema opened.

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 an explicit trigger ('before create_transfer') and an explicit reason to prefer it over the naive path ('instead of spending a short-lived quote on a rejected transfer'). The alternative it displaces and the cost of skipping it are both spelled out.

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