ap2-iso20022
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| normalize_ap2A | Normalise a Google AP2 (Agent Payments Protocol) mandate payload into a canonical mandate the other tools accept. |
| normalize_x402A | Normalise a Coinbase x402 (HTTP-402) payment requirement/receipt into a canonical mandate the other tools accept. |
| check_mandateA | Guardrail a mandate before it becomes a payment: check required fields, the spending cap (amount <= max_amount), expiry (when 'as_of' is supplied), and whether an authorisation proof is present. Returns ok plus any violations and warnings. Run this before converting. |
| to_pain001A | Convert a canonical mandate into a pain.001 record (customer credit transfer initiation) using the exact field names pain001 expects, so it feeds straight into pain001 generate_message for wire-valid XML. |
| to_pacs008A | Convert a canonical mandate into a pacs.008 record (FI-to-FI credit transfer) using the field names pacs008 expects, for interbank settlement of an agent-authorised payment. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool targets a distinct operation: two normalization for different input formats, one validation, and two conversions to different ISO 20022 messages. No overlap in purpose.
Most tools follow a verb_noun pattern (normalize_ap2, normalize_x402, check_mandate), but to_pain001 and to_pacs008 use 'to' instead of a verb. Still consistent and readable.
Five tools cover the core pipeline—normalization, validation, and two output formats—without being excessive or insufficient for the stated domain.
The set covers the main workflow: input normalization, mandate validation, and conversion to two common ISO 20022 messages. Minor gaps like reverse conversion or a generic normalize could exist but are not essential.