Skip to main content
Glama

get_payment_methods

Read-only

List available payment processors and their capabilities. Returns Yoco (card, immediate) and Ozow (instant EFT via South African bank account). Call when the customer asks 'how can I pay?' or before presenting options. The result informs the payment_method field in create_checkout and complete_checkout.

Input Schema

NameRequiredDescriptionDefault
order_total_zarNoOptional. For future per-handler limit filtering.

Output Schema

NameRequiredDescriptionDefault
noteYes
handlersYes
default_currencyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • removedOutput schema / properties / handlers / items / properties / display_name
      Removed value: -{
      -  "type": "string"
      -}
    • removedOutput schema / properties / handlers / items / properties / methods
      Removed value: -{
      -  "items": {
      -    "type": "string"
      -  },
      -  "type": "array"
      -}
    • addedOutput schema / properties / handlers / items / properties / name
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / handlers / items / properties / note
      Added value: +{
      +  "type": "string"
      +}
    • removedOutput schema / properties / handlers / items / properties / redirect
      Removed value: -{
      -  "type": "boolean"
      -}
    • addedOutput schema / properties / handlers / items / properties / supports
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • removedOutput schema / properties / handlers / items / properties / supports_3ds
      Removed value: -{
      -  "type": "boolean"
      -}
    • removedOutput schema / properties / handlers / items / properties / supports_banks
      Removed value: -{
      -  "items": {
      -    "type": "string"
      -  },
      -  "type": "array"
      -}
    • removedOutput schema / properties / handlers / items / properties / webhook_verified
      Removed value: -{
      -  "type": "boolean"
      -}
    • changedOutput schema / properties / handlers / items / required
      Previous value: -[
      -  "id",
      -  "display_name",
      -  "methods",
      -  "redirect",
      -  "webhook_verified"
      -]New value: +[
      +  "id",
      +  "name",
      +  "supports"
      +]
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "default_currency": {
      +      "const": "ZAR",
      +      "type": "string"
      +    },
      +    "handlers": {
      +      "items": {
      +        "additionalProperties": true,
      +        "properties": {
      +          "display_name": {
      +            "type": "string"
      +          },
      +          "id": {
      +            "type": "string"
      +          },
      +          "methods": {
      +            "items": {
      +              "type": "string"
      +            },
      +            "type": "array"
      +          },
      +          "redirect": {
      +            "type": "boolean"
      +          },
      +          "supports_3ds": {
      +            "type": "boolean"
      +          },
      +          "supports_banks": {
      +            "items": {
      +              "type": "string"
      +            },
      +            "type": "array"
      +          },
      +          "webhook_verified": {
      +            "type": "boolean"
      +          }
      +        },
      +        "required": [
      +          "id",
      +          "display_name",
      +          "methods",
      +          "redirect",
      +          "webhook_verified"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "note": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "default_currency",
      +    "handlers",
      +    "note"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: what is returned (card vs. instant EFT via South African bank account) and how the output feeds create_checkout/complete_checkout. It stops short of mentioning auth or caching/rate behavior, so not a 5.

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 what the tool returns, then when to call it, then why it matters. Every sentence adds information an agent needs; nothing is redundant with the title or schema.

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

Completeness5/5

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

An output schema exists, so return values need not be re-specified, and the only parameter is optional and fully documented. Purpose, trigger, expected content, and downstream dependency are all present for a simple read-only lookup.

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?

The single optional parameter order_total_zar is not mentioned in the description, but schema description coverage is 100% and the schema itself explains it is reserved for future per-handler limit filtering. With the schema carrying the load, the baseline of 3 applies.

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 ("List available payment processors and their capabilities") and even enumerates the concrete return values, Yoco and Ozow. An agent can immediately tell this is the payment-options discovery tool and distinguish it from checkout-mutating siblings like create_checkout.

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?

Gives an explicit trigger ("Call when the customer asks 'how can I pay?' or before presenting options") and names the downstream tools whose payment_method field depends on the result. It provides clear usage context but no when-not conditions, which is acceptable since no sibling offers an overlapping capability.

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.