SwapEazi

Read the SwapEazi Payment Index

payment_index

Read-only

Lists real cross-border payment outcomes per corridor and size band: date, corridor, size band, route type (bank, payout_network, otc, exchange, stablecoin, card), the all-in cost in bps against the official or mid-market reference of that day, what the figure is (a payment that landed, receipt figures, a quoted rate, a published rate, a P2P advert median) and a source label on every row: MEASURED (SwapEazi's own reads and receipts), PUBLIC REPORT (a published rate, with its link), SELF-REPORTED (submitted by a business) or VERIFIED (submitted with a receipt SwapEazi matched). Also medians per corridor, size band and source; sources are never pooled. Providers are masked unless the submitter chose to name them. A record, not advice, not a quote and not a ranking. Free; same as GET /api/v1/index/payments.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "payment_index"
  }
}

Input Schema

Name	Required	Description
`to`	No	Currency received, e.g. 'ZAR'.
`from`	No	Currency sent, e.g. 'EUR'.
`size`	No	Size band: under_20k_usd, 20k_100k_usd, 100k_1m_usd, 1m_10m_usd, 10m_plus_usd, unknown_size or all_sizes (a rate, any size).
`year`	No	Four digits, e.g. '2026'.
`limit`	No	Rows to return, 1 to 500 (default 100).
`route`	No	Route type: bank, payout_network, otc, exchange, stablecoin, card or not_stated.
`offset`	No	Rows to skip, for paging (next_offset from the last answer).
`source`	No	measured, public_report, self_reported or verified.
`corridor`	No	Two currency codes, e.g. 'ZAR-MZN'. Or use from and to.
`currency`	No	Rows where this currency is sent or received.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial behavior the annotations do not: the four source labels and what each means (MEASURED, PUBLIC REPORT with link, SELF-REPORTED, VERIFIED), the rule that sources are never pooled, that medians are returned per corridor/size band/source, and that providers are masked unless the submitter opted in. That masking and non-pooling behavior materially changes how results should be interpreted and is exactly the kind of context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and the key disclaimers are front-loaded, and no sentence is filler. The parenthetical enumerations of route types and figure kinds are dense and partially duplicate the schema's value lists, costing some tightness.

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

Completeness4/5

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

For a ten-parameter, no-required-argument index read with no output schema, the description covers what rows contain, how sources are labeled and kept separate, masking, and cost against the official/mid-market reference. It does not mention default ordering or how offset/next_offset paging behaves beyond the schema hint, which is a minor remaining gap.

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?

Schema coverage is 100%, so all ten parameters are already documented in the schema, including the route, size and source value lists the description repeats. The description adds only a little framing (corridor/size-band grouping, the notion that size bands correspond to cost comparisons), so the schema does the heavy lifting and a baseline 3 is appropriate.

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 ('Lists real cross-border payment outcomes per corridor and size band') and then enumerates the returned fields (date, corridor, size band, route type, all-in cost in bps, figure type, source label). The closing disclaimer 'A record, not advice, not a quote and not a ranking' separates it from quote/recommendation siblings like price_routes or recommend_payment_route without naming them.

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?

The 'not advice, not a quote and not a ranking' framing tells an agent this is the historical/observational read, implicitly routing quoting and recommendation work elsewhere. It also notes it is free and equivalent to GET /api/v1/index/payments, which helps with selection. It never explicitly names an alternative or states a when-not-to-use condition, so it stops short of a 5.

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

All SwapEazi tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?