Skip to main content
Glama

Crosswire - payment infrastructure pricing, coverage and stack design

Check Crosswire coverage

check_coverage
Read-onlyIdempotent

Call this whenever the user asks where Crosswire operates, whether a country or region is served, or what is available in a market - never answer coverage from the website or prior knowledge. Use when the user asks whether Crosswire covers a region or country, or what capabilities are available there. Regions are the canonical set: Europe, UK, UAE, US, Canada, LATAM, Asia, Africa. Region names are matched case-insensitively and echoed back in canonical casing. Optionally pass product (banking, acquiring, digital-assets, cross-border, open-banking, kyc, baas, vibans, agentic; legacy aliases such as crypto, corridor, open_banking and fixed-txn are accepted and normalise) to scope the answer; product 'cross-border' (alias 'corridor') always returns the real-time EUR <-> USD settlement corridor block (live for EU <-> US). Describes capability level only and never names a provider, bank, acquirer or network. Pass vertical and currency when known: the answer then states whether a row underwrites that vertical on that rail and which settlement currencies it is priced in, rather than a bare regional yes. PAYOUTS: product 'payouts' answers per DESTINATION market with the SETTLEMENT METHODS that destination is reachable on - bank deposit, wallet, cash pickup or card - plus the service types, the turnaround, the limits and the route status, all read from the pinned payout-routes export and never from prose. Name no network, scheme or provider: a card payout is a method, not a brand. Where a route is eligible for banks only the answer says it is available to regulated financial institutions with confirmation required for others, and nothing more. A payout answer never carries corridor copy, because a corridor and a payout are different components. A regional payouts question returns the family with its route counts; a family is never reported as live, its routes are. OPEN BANKING: product 'open-banking' answers per MARKET from the recorded market rows - whether the market is live per the provider's own published market list and when that was read, how many banks are reachable there (unknown where it is not recorded, never estimated), and the settlement currency status. A vertical the provider lists but has not confirmed in writing reads 'listed by the provider, written confirmation pending', never 'not underwritten', and an open dependency keeps the vertical answer at consult with the dependency named. A market with no recorded row is answered as before. No provider, bank or source page is ever named. Does NOT return pricing - for any price/rate question use get_indicative_price (which accepts the same product values). SCOPE: the answer is scoped to the region asked about. The payout, Current and corridor families that region touches come back in full; every other family comes back as a count, and the public network as membership without each member's licence register entry. Every guardrail, pricing note and status sentence is unchanged either way. Pass full_inventory: true only when the user explicitly asks for the complete inventory.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionYesRegion or country (e.g. 'Germany', 'US', 'Hong Kong', 'LATAM').
productNoOptional product to scope coverage to. Same canonical enum as get_indicative_price. Legacy aliases (corridor, crypto, open_banking, pay-by-bank, fixed-txn) are accepted and normalise.
currencyNoOptional settlement currency (ISO 4217, e.g. 'EUR', 'USD', 'GBP'). Coverage states which currencies the rail is priced in.
verticalNoOptional vertical (e.g. 'Adult / Dating', 'Forex / CFD', 'Crypto', 'iGaming', 'Nutra / supplements'). Supply it whenever the user has one: coverage answers differently per vertical, because a region can serve a product while no row underwrites that vertical on it.
full_inventoryNoDefault false. Coverage is scoped to the region asked about: the payout, Current and corridor families that region touches are returned in full, everything else as a count, and the public network as membership without each member's licence record. Set true ONLY when the user explicitly asks for the complete inventory - every family, every route, every register entry. A scoped answer states the same facts; it carries less inventory.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, but the description goes far beyond them: it discloses guardrails (never names a provider, bank, acquirer or network), how unconfirmed verticals are phrased, how missing market rows are answered, and that results come from a pinned export rather than prose. This is unusually rich behavioral context for a read-only tool.

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

Conciseness2/5

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

The first sentence front-loads well and PAYOUTS/OPEN BANKING/SCOPE headers help, but the description is a wall of dense prose with repeated rules (the 'never name a provider/network' guardrail appears at least three times) and buries the practically important flag semantics far from the top. Many sentences do not earn their place.

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 complex, multi-family tool with no output schema, it covers the main answer shapes (regional, payout, open banking, corridor, scoped inventory) and failure modes (unrecorded rows, unconfirmed verticals). Completeness is high; the tangled prose makes it harder than it needs to be to confirm the answer contract.

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 100%, so the baseline is 3, and the description adds real meaning on top: it explains that legacy aliases normalise, that 'cross-border' always returns the EUR<->USD corridor block, and how vertical/currency change the shape of the answer. The gating logic for full_inventory is meaningful, though some of the enum detail merely restates the schema.

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 (check) and resource (Crosswire coverage) and enumerates exactly what it answers: where Crosswire operates, whether a country/region is served, what capabilities exist in a market. It is clearly distinguishable from siblings such as get_indicative_price, which it explicitly delegates pricing questions to.

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?

Gives an explicit trigger ('call this whenever the user asks...') , an explicit prohibition ('never answer coverage from the website or prior knowledge'), and names the alternative for out-of-scope questions ('Does NOT return pricing - for any price/rate question use get_indicative_price'). It even scopes the full_inventory flag to an explicit user request.

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.

Resources