Skip to main content
Glama
Sign In
Stables MCP Server

Stables MCP Server

Official
by stables-money
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List payment routes

list_virtual_accounts
Read-onlyIdempotent

List payment routes (virtual accounts) for a single customer or across all customers when customerId is omitted, with optional status filtering and pagination.

Instructions

List payment routes (virtual accounts) for one customer, or across every customer when customerId is omitted

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_virtual_accounts"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of accounts to return
statusNoFilter by account status
customerIdNoOnly this customer's routes; omit to list routes across all customers
startingAfterNoReturn routes after this route ID (the last ID of the previous page)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.6.11
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed3 schema fields changedv2.4.0
    • changedInput schema / properties / customerId / description
      Previous value: -"The customer ID to list virtual accounts for"New value: +"Only this customer's routes; omit to list routes across all customers"
    • addedInput schema / properties / startingAfter
      Added value: +{
+  "description": "Return routes after this route ID (the last ID of the previous page)",
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "customerId"
-]
  3. First observedv1.4.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds the scoping behavior (all customers when customerId is absent) but says nothing about result volume, pagination behavior, or default limit, which matters for a global list.

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?

A single front-loaded sentence with no filler; the parenthetical terminology mapping earns its place. It is arguably too short for the global-list case, but nothing is redundant.

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 read-only list tool with a fully documented schema and rich annotations, the description covers what the agent needs to invoke it correctly. Missing only minor context about default page size and result ordering, which the limit and startingAfter parameters imply.

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 description coverage is 100%, so every parameter is already documented including the omit-customerId semantics. The description reinforces that one behavior but adds no syntax, defaults, or format detail beyond the schema, 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 the specific verb (List) and resource (payment routes / virtual accounts), and bridges the two naming conventions used elsewhere in the API. It does not explicitly contrast with siblings like get_virtual_account_history or create_virtual_account, but the list-vs-single-resource distinction is implicit and clear.

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?

The description does cover the two usage modes — scoped to one customer versus global — via the customerId omission rule. It gives no guidance on when to prefer this over adjacent tools such as list_route_whitelist or get_virtual_account_history, so the agent must infer the boundary.

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