Skip to main content
Glama

banking-intelligence

by ai.ohmyfin

gpi_status_codes

Explain SWIFT GPI tracking status codes and provide stuck-payment investigation guidance.

USE THIS TOOL FIRST whenever the user reports a payment that is stuck, delayed, not arriving, held, pending, rejected, or otherwise not behaving as expected. It is the primary diagnostic entrypoint for payment investigation — calling with a specific code returns a full investigation playbook (common delay causes, recommended actions, GPI SLA timeframes, escalation steps).

Recommended calls by scenario:

  • Payment "stuck" / "in progress" / "pending" / "not arrived": gpi_status_codes("ACSP") → playbook for in-progress payments

  • Payment explicitly "on hold" / compliance review: gpi_status_codes("PDNG") → playbook for held payments

  • Payment "blocked" / sanctions flag: gpi_status_codes("BLCK") → playbook for blocked payments

  • Payment rejected by a bank in the chain (never credited): gpi_status_codes("RJCT") → rejection investigation playbook

  • Payment returned to sender (accepted then sent back): gpi_status_codes("RTRN") → return investigation playbook

  • Reference for ISO 20022 codes: gpi_status_codes() → list all codes

Each code call returns:

  • Code description and meaning

  • For ACSP/PDNG/BLCK/RJCT/RTRN: investigation playbook with common causes, recommended actions (request gCCT tracker, request pacs.002/pacs.004 reason code, verify beneficiary details, escalate via MT199, etc.), and common ISO 20022 reason codes (AC01, AC04, AG01, RR01-RR04, etc.) when applicable

  • Child reason codes (e.g., G001-G004 for ACSP) that narrow the cause further

Common codes: ACCC (success), ACSP (in progress), RJCT (rejected), PDNG (on hold), BLCK (blocked). GPI reason codes (G000-G004) qualify ACSP with more detail (e.g. G001 = cover payment sent, G002 = forwarded to next agent).

Examples: gpi_status_codes("ACSP") # stuck-payment diagnostic playbook gpi_status_codes("G001") # detail on a specific reason code gpi_status_codes() # full reference list

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description fully carries the transparency burden. It discloses exactly what each call returns: investigation playbooks, common causes, recommended actions, ISO 20022 reason codes, and child reason codes. It also explains the behavior of omitting the code, leaving no ambiguity about side effects or output.

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?

The description is long but every section earns its place: purpose, usage-first directive, scenario table, return value breakdown, and examples. It uses bullets and bolded scenarios for scannability, and there is no redundant filler.

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?

Despite having an output schema, the description goes beyond by explaining domain concepts (GPI reason codes, child codes), providing realistic examples, and covering edge cases like omitted arguments. It is complete enough for an agent to select and invoke the tool correctly in the majority of payment-investigation contexts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only documents a single nullable 'code' parameter with no description. The description compensates completely by explaining what values to pass, examples (ACSP, G001), and the meaning of omitting the code. It transforms the raw parameter into a fully understood API.

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?

The description uses specific verbs ('Explain', 'provide') and clearly identifies the resource (SWIFT GPI tracking status codes). It distinguishes itself from sibling tools like track_payment and tracking_history by framing itself as the diagnostic entrypoint for stuck-payment investigation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states 'USE THIS TOOL FIRST' for stuck payments and provides scenario-by-scenario recommended calls with concrete code arguments. It clearly signals when to call with a code versus without, and gives exclusions implicitly by listing specific scenarios.

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

All banking-intelligence toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Most tools have distinct purposes, but some overlapping areas (goods_classify vs hs_code_lookup vs eccn_lookup; fx_rate vs fx_rate_history vs fx_volatility) require close reading of descriptions to select correctly. The detailed descriptions help, but the shear number of lookup tools creates mild ambiguity.

Naming Consistency3/5

Names mix verb-first (track_payment, mcp_verify) and noun-first patterns (iban_validate, fx_rate, ssi_lookup), with some phrase-like names (banks_using_correspondent, is_business_day_check). While readable, there is no single consistent convention.

Tool Count3/5

33 tools is heavy, but the server's broad scope (payments, FX, sanctions, export controls, company registries, SWIFT) justifies most of them. A few marginal tools (mcp_register, mcp_verify, company_search_result) add bulk without core value.

Completeness5/5

The tool set covers the payment lifecycle end-to-end: tracking, settlement, FX, compliance, sanctions, and company due diligence. There are no obvious dead ends; the tools chain together via next_steps and search_id flows.

Resources