Crosswire - payment infrastructure pricing, coverage and stack design

Recommend a Crosswire stack

recommend_stack

Read-onlyIdempotent

Call this whenever the user asks which Crosswire products or rails fit their setup, and price is not the question. Use ONLY when the user asks which Crosswire products/rails fit their setup - not price. Accepts either a free-text description of the business (preferred) or structured vertical + needs; every supplied input is read, echoed back in fields, and never asked for again. Returns a recommended combination of rails with a short rationale, each rail carrying the need or cue it was derived from. Does NOT return pricing, rates, bps, fees, savings, or any commercial number. For any price/rate/cost/fee question, use get_indicative_price instead. Sensitive verticals (forex, adult) return a consult, never a firm stack. When EU and US movement are both in scope, the response also carries the real-time EUR <-> USD settlement corridor. Rails are described at capability level only - no provider, bank, acquirer or network is ever named.

Input Schema

TableJSON Schema

Name	Required	Description
`needs`	No	Capabilities the client needs. Each one produces exactly one rail.
`regions`	No
`activity`	No	What the entity does, e.g. 'fiat-crypto conversion for retail'.
`vertical`	No	Business vertical, one of: e-commerce, saas, standard, marketplace, banking, crypto, igaming, adult, forex, other. Common aliases (crypto exchange, online casino, gambling, ecommerce, CFD, dating, fintech...) are accepted and normalised silently; the canonical value is relayed back in the response. Required unless `description` is given.
`casp_status`	No	EU CASP (MiCA) authorisation status of the client: authorised \| in_application \| not_required \| none. REQUIRED before any crypto or digital-asset answer - a band, a rail or an architecture - is returned for a European flow: it decides whether providers may serve the client in the EU at all. Ask it early, in the client's own words, and pass the answer back on the same tool. This is NOT the `licensed` boolean, which covers vIBANs and agentic only.
`description`	No	Free-text description of the business. Preferred over structured inputs.
`optimise_for`	No	Re-sequence the SAME architecture for one priority: cost, speed or working_capital. Never changes pricing.
`end_user_type`	No	Who its end users are, e.g. 'EEA retail customers'.
`incorporation`	No	Where the entity is incorporated, e.g. 'Canada'. Part of the entity question: who may hold the account.
`registrations`	No	What the entity is registered as, e.g. 'FINTRAC registered money services business'. A registration outside the EU/EEA never answers the CASP question.
`target_launch`	No	Target launch date or timeframe, e.g. 2026-10-01 or 'Q4 2026'.
`engagement_ref`	No	Optional engagement reference issued by Crosswire after a human approved the engagement. Never assertable by claim: only a valid, unexpired, unrevoked reference unlocks the named proposal. Anything else is treated as absent.
`monthly_volume`	No
`avg_transaction_eur`	No	Average transaction size. Read into the profile; never re-asked once supplied.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 16, 2026

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"
+}

Changed6 schema fields changedSep 15, 2026

changedInput schema / properties / casp_status / description

Previous value: -"EU CASP (MiCA) authorisation status of the client. REQUIRED before any crypto or digital-asset rail can be recommended: authorised | in_application | not_required | none. Ask the user this early - it decides whether providers can serve them in the EU at all."New value: +"EU CASP (MiCA) authorisation status of the client: authorised | in_application | not_required | none. REQUIRED before any crypto or digital-asset answer - a band, a rail or an architecture - is returned for a European flow: it decides whether providers may serve the client in the EU at all. Ask it early, in the client's own words, and pass the answer back on the same tool. This is NOT the `licensed` boolean, which covers vIBANs and agentic only."

changedInput schema / properties / casp_status / enum

Previous value: -[
-  "authorised",
-  "in_application",
-  "not_required",
-  "none"
-]New value: +[
+  "authorised",
+  "in_application",
+  "not_required",
+  "none",
+  "other"
+]

changedInput schema / properties / vertical / description

Previous value: -"Business vertical."New value: +"Business vertical, one of: e-commerce, saas, standard, marketplace, banking, crypto, igaming, adult, forex, other. Common aliases (crypto exchange, online casino, gambling, ecommerce, CFD, dating, fintech...) are accepted and normalised silently; the canonical value is relayed back in the response. Required unless `description` is given."

addedInput schema / properties / vertical / enum

Added value: +[
+  "e-commerce",
+  "saas",
+  "standard",
+  "marketplace",
+  "banking",
+  "crypto",
+  "igaming",
+  "adult",
+  "forex",
+  "other"
+]

removedInput schema / properties / vertical / maxLength
```
Removed value: -60
```
removedInput schema / properties / vertical / minLength
```
Removed value: -2
```

First observedSep 14, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, but the description adds substantial behavioral detail beyond that: it returns a combination of rails with rationale, does NOT return any commercial numbers, handles sensitive verticals with a consult, includes a EUR/USD corridor when both regions are in scope, and never names providers/banks. It also explains that supplied inputs are echoed back and never re-asked. This is thorough and does not contradict 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?

The description is long but every sentence carries essential information. It front-loads the primary usage, then covers constraints, output, exclusions, and edge cases in a logical order. There is no fluff or repetition; each clause adds clarity. The structure makes it easy for an agent to extract the core behavior quickly.

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 (14 parameters, no output schema), the description is remarkably complete. It explains the output content (combination of rails, rationale, need/cue mapping), what it does NOT return, sensitive-vertical behavior, EU/US corridor logic, and the provider-agnostic nature of rails. No critical behavioral detail is missing; an agent has everything needed to invoke it correctly.

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 86% (high), so the baseline is 3. The description adds value beyond the schema by noting that free-text `description` is preferred over structured `vertical` + `needs`, that every supplied input is echoed back and never asked again, and that CASP status is required before any crypto answer. These are useful semantic hints not present in the schema, elevating the score above baseline, though not to 5 since the schema already documents most parameters.

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 states a precise purpose: recommend Crosswire rails/products for a given setup, with the explicit scope condition 'price is not the question.' It also names the sibling tool it is not (get_indicative_price), distinguishing it from a closely related alternative. The verb 'recommend' plus the resource 'Crosswire stack' is clear and specific.

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?

The description explicitly states when to call this tool: whenever the user asks which Crosswire products/rails fit their setup, and not for price. It also gives an explicit exclusion: 'For any price/rate/cost/fee question, use get_indicative_price instead.' This provides clear when-to-use and when-not-to-use guidance with a named alternative.

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

All Crosswire - payment infrastructure pricing, coverage and stack design 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?