Skip to main content
Glama

Payout options

get_payout_options
Read-onlyIdempotent

Lists where money can be paid out to a bank account: the country, the currency it arrives in, the method, the fee, the largest amount and how fast it arrives, for personal and business accounts. Give a country, a currency or both. Use it when someone asks whether they can send money to a country, what it costs or how long it takes.

Input Schema

NameRequiredDescriptionDefault
countryNo
currencyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds useful context beyond that: both filters are optional and combinable, and it enumerates what the result rows contain in lieu of an output schema. No pagination, ordering, or result-size behavior is mentioned.

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, front-loaded with the returned fields, then the input rule, then the usage trigger. The field enumeration is dense but every item is meaningful, and there is no filler.

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?

With no output schema, describing the result columns is exactly the right compensation, and annotations cover the safety/mutation profile. The remaining gap is the input format (country/currency code conventions) and what happens when both filters are omitted.

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 0%, so the description must carry the load. 'Give a country, a currency or both' establishes validity when omitted and that they combine, but it never says the values are ISO-style codes (the ^[A-Z]{2}$ / ^[A-Z]{3}$ patterns imply this but the description doesn't), nor whether names are accepted.

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?

Specific verb+resource ('Lists where money can be paid out to a bank account') plus an enumeration of the returned fields (country, currency, method, fee, max amount, speed). It is clearly distinguishable from quote-oriented siblings like get_send_quote/get_receive_quote, though it never names an alternative explicitly.

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?

Explicit when-to-use trigger: 'Use it when someone asks whether they can send money to a country, what it costs or how long it takes.' No when-not cases or named alternatives are given, so it falls short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources