payments-toolkit-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port for the Streamable HTTP transport (default 3000). Only used when starting the server in HTTP mode. | 3000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| validate_card_numberA | Checks whether a card number passes the Luhn checksum algorithm. Accepts digits only (spaces/dashes should be stripped by the caller). |
| detect_card_typeA | Identifies the card network (Visa, Mastercard, American Express, Discover, Diners Club, JCB) from the card number's IIN/BIN prefix. Accepts digits only (spaces/dashes should be stripped by the caller). |
| validate_ibanA | Validates an International Bank Account Number (IBAN): checks the country-specific length and the ISO 13616 mod-97 checksum. Spaces are stripped and letters are case-insensitive. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| card_networks | Supported card networks and the IIN/BIN prefix ranges used to identify them. |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: validate_card_number checks Luhn, detect_card_type identifies network via prefix, and validate_iban validates IBAN. No overlap between card validation and IBAN validation, and card type detection is a separate concern.
All tools follow the verb_noun pattern (validate_*, detect_*), but there's a slight inconsistency: 'validate_card_number' uses 'card_number' while 'detect_card_type' uses 'card_type', but both are clear and consistent in style. Minor deviation from uniform noun usage.
With only 3 tools, the server is focused but feels slightly thin for a 'payments-toolkit'. The scope is narrow (validation/detection), but it could benefit from additional related tools like card expiry validation or payment amount validation. However, it's not egregiously under-scoped.
The server covers card number validation and type detection and IBAN validation, which are core payment validation tasks. However, it omits other common validations (e.g., CVV, expiry date, bank account routing numbers) and any operations beyond validation (e.g., formatting, masking). The gaps are notable but the main validation lifecycle is present.