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.
activityNoWhat the entity does, e.g. 'fiat-crypto conversion for retail'.
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.
end_user_typeNoWho its end users are, e.g. 'EEA retail customers'.
incorporationNoWhere the entity is incorporated, e.g. 'Canada'. Part of the entity question: who may hold the account.
registrationsNoWhat the entity is registered as, e.g. 'FINTRAC registered money services business'. A registration outside the EU/EEA never answers the CASP question.
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. Changed1 schema field changed
    • changedInput schema / properties / product / enum
      Previous value: -[
      -  "banking",
      -  "acquiring",
      -  "digital-assets",
      -  "cross-border",
      -  "open-banking",
      -  "kyc",
      -  "baas",
      -  "vibans",
      -  "agentic",
      -  "payment-ops",
      -  "compliance-automation",
      -  "payouts",
      -  "current"
      -]New value: +[
      +  "banking",
      +  "acquiring",
      +  "digital-assets",
      +  "cross-border",
      +  "open-banking",
      +  "kyc",
      +  "baas",
      +  "vibans",
      +  "agentic",
      +  "payment-ops",
      +  "compliance-automation",
      +  "payouts",
      +  "current",
      +  "card-issuing"
      +]
  2. Changed4 schema fields changed
    • addedInput schema / properties / activity
      Added value: +{
      +  "description": "What the entity does, e.g. 'fiat-crypto conversion for retail'.",
      +  "maxLength": 160,
      +  "minLength": 2,
      +  "type": "string"
      +}
    • addedInput schema / properties / end_user_type
      Added value: +{
      +  "description": "Who its end users are, e.g. 'EEA retail customers'.",
      +  "maxLength": 120,
      +  "minLength": 2,
      +  "type": "string"
      +}
    • addedInput schema / properties / incorporation
      Added value: +{
      +  "description": "Where the entity is incorporated, e.g. 'Canada'. Part of the entity question: who may hold the account.",
      +  "maxLength": 80,
      +  "minLength": 2,
      +  "type": "string"
      +}
    • addedInput schema / properties / registrations
      Added value: +{
      +  "description": "What the entity is registered as, e.g. 'FINTRAC registered money services business'. A registration outside the EU/EEA never answers the CASP question.",
      +  "items": {
      +    "maxLength": 120,
      +    "minLength": 2,
      +    "type": "string"
      +  },
      +  "maxItems": 8,
      +  "type": "array"
      +}
  3. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond annotations (readOnly, idempotent), the description discloses substantial behavioral details: canonical region casing, legacy alias normalization, product-specific behavior (cross-border corridor, payouts per destination, open-banking per market), scope contraction with counts vs full families, and guardrails against naming providers or schemes. No contradiction with annotations.

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?

Long but every sentence carries a guardrail or behavioral fact essential for correct invocation. Structured with scannable sections (PAYOUTS, OPEN BANKING, SCOPE) and front-loaded with the primary purpose. No fluff or repetition of schema contents.

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 no output schema, the description covers all necessary behavioral contract: canonical regions, case-insensitivity, product-specific answers, scoping, exclusions, and guardrails for payout/open-banking/current/corridor families. The only minor gap is handling of unrecognized region strings, but the canonical set and matching rules make this negligible.

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?

Schema coverage is 100% but the description significantly enriches parameter meaning. For 'product' it explains legacy aliases and per-product output behavior; for 'vertical' and 'currency' it clarifies how they change the answer; for 'full_inventory' it defines the exact scoping semantics and when to set true. This is far beyond the schema's bare property descriptions.

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+resource ('check Crosswire coverage') and immediately distinguishes itself from siblings by naming when it applies ('where Crosswire operates... what is available in a market'). Also explicitly contrasts with get_indicative_price at the end. The name/title is expanded into a full operational scope.

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?

Provides explicit when-to-use conditions ('Call this whenever...'), while also naming exclusions ('never answer coverage from the website or prior knowledge') and pointing to the alternative for pricing questions ('use get_indicative_price'). Gives clear trigger phrases and conditions for optional parameters, e.g. when to pass vertical/currency.

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