Skip to main content
Glama

tracking_history

Show how a SWIFT payment's tracking results changed over time.

Returns the DISTINCT tracking results recorded for a payment (by UETR or reference), deduplicated so ten identical re-tracks collapse to one entry while any change — a new last-update, a status change, or new bank data — appears as its own entry. Each entry includes what was ENTERED when the search was run (amount, currency, date) alongside the banks that reported data and their confirmed amount / value date.

WHEN TO USE THIS:

  • The user says the page shows different data than you see, or asks why a bank line (e.g. JP Morgan) "disappeared" or a value date differs.

  • You need to reconcile an amount discrepancy. Correspondent banks such as JP Morgan return their confirmation ONLY when the tracked amount exactly matches the payment, so a search run with the wrong amount silently drops their line. Comparing entries here — same UETR, different entered amounts, different bank data — is how you spot that the amount was the problem.

  • Before concluding "the record was consolidated" or "the bank stopped reporting", check the history: the earlier result you're being asked about is usually still here, under a different entered amount.

Only results for the current user (plus system tracks with no owner) are returned; other users' searches of the same UETR are never shown.

Requires an API key with an active FI subscription.

Args: uetr: UETR (UUID v4) of the payment. Strongly preferred. reference: Sender's reference (MT103 Field 20) — used when no UETR.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uetrNo
api_keyNo
referenceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.9/5.0
Behavior5/5

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

Despite no annotations, the description fully discloses behavioral traits: deduplication of identical tracks, only results for current user + system tracks, requirement of an API key with active FI subscription. It explains limitations like not showing other users' data and that entries include what was entered vs. bank confirmations.

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 well-structured with clear sections: a summary paragraph, a bullet-style usage guide, visibility note, API requirement, and Args list. Every sentence adds value without redundancy, and the format enhances readability for an AI agent.

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?

Given the tool's complexity and that it has an output schema, the description covers all necessary aspects: what the tool returns (distinct entries with entered data and bank details), deduplication logic, user scope, and prerequisites. It prepares the agent for interpreting results (e.g., amount discrepancies) and explains constraints thoroughly.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate. It provides detailed semantics for 'uetr' (strongly preferred) and 'reference' (used when no UETR) in an 'Args' section. However, the 'api_key' parameter is only mentioned in the body text without explanation of its purpose or behavior in the args section, leaving a small gap.

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 clearly states the tool shows how tracking results changed over time, distinct from sibling tools like track_payment that show current status. It provides a specific verb ('Show') and resource ('tracking history') with clear deduplication behavior.

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?

Includes a dedicated 'WHEN TO USE THIS' section with three explicit scenarios (page discrepancy, amount reconciliation, before concluding consolidation). It also explains when not to use it and what alternatives to consider, e.g., 'check the history' before assuming data loss.

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.

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