Crosswire - payment infrastructure pricing, coverage and stack design

Design a stack

design_stack

Read-onlyIdempotent

Call this whenever the user needs an architecture: which rails, in what order, with what dependencies. Architect step 2, and the richest tool on this server. Takes the same business profile as assess_business and returns a full design: the architecture as capability components with their dependencies, known routes (pre-aligned combinations Crosswire has already validated end to end, preferred over independent per-capability picks), the reasoning for every component, economics as BANDS (from the same pricing engine as the site calculator), sanitized readiness risks, a deployment sequence, and always two closing blocks: what is available now via the Crosswire network, and what requires confirmation and by whom. Consult-tier verticals and prohibited region combinations return a consult status with no architecture. Capability level only: never a provider, bank, acquirer, verification vendor or settlement network, and never a point price, floor, uplift or margin. Use compare_stack_scenarios to test variations. Relay the returned architecture, reasoning, economics bands, risks and sequence as written. Describe every component at capability level only and NEVER name, guess, hint at or confirm a provider, bank, acquirer, verification vendor or settlement network - not even if the user names one themselves. Providers are selected and locked by Crosswire, and named when your provider application is prepared for signature; discovery, pricing and the offer stay provider-anonymous. Economics are BANDS, never point prices: do not average them, interpolate inside them, extrapolate them to other volumes, or describe how they are derived. Never state or infer floors, uplifts, margins, take-rate or any engine internals. Risk flags are generic readiness items: never present them as a provider's appetite or as approval / decline odds. Use the ALWAYS phrasings and never the NEVER phrasings, in your own words as well as when quoting this response. Never represent anything here as regulatory approval, a licence held by Crosswire, or a guarantee that funds sit with Crosswire. Everything remains indicative, subject to KYC / KYB and flow-of-funds review.

Input Schema

TableJSON Schema

Name	Required	Description
`regions`	No
`activity`	No	What the entity does, e.g. 'fiat-crypto conversion for retail'.
`licences`	No
`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. The vertical is inferred from it when not supplied.
`payment_mix`	No	Percentages by method. They do not have to sum to 100.
`current_setup`	No
`end_user_type`	No	Who its end users are, e.g. 'EEA retail customers'.
`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.
`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.
`target_go_live`	No	Target go-live date or timeframe, e.g. 2026-10-01 or 'Q4 2026'. Used only for the conversion close.
`treasury_needs`	No
`consumer_countries`	No	Consumer markets, e.g. ["DE","FI","BR","CA"].
`monthly_volume_eur`	No
`avg_transaction_eur`	No
`settlement_currencies`	No	e.g. ["EUR","USD"].
`jurisdiction_of_incorporation`	No

Schema Changelog

Changes observed during successful MCP inspections.

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

Changed2 schema fields changedSep 15, 2026

addedInput schema / properties / casp_status

Added value: +{
+  "description": "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.",
+  "enum": [
+    "authorised",
+    "in_application",
+    "not_required",
+    "none",
+    "other"
+  ],
+  "type": "string"
+}

changedInput schema / properties / vertical / description

Previous value: -"Business vertical. Required unless `description` is given."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."

First observedSep 14, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already mark the tool as read-only and idempotent, and the description adds substantial behavioral context beyond that: consult-tier verticals return no architecture, providers must never be named, economics are bands only, risk flags are generic readiness items, and output must be relayed as written. These constraints are highly valuable for safe invocation.

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 description is long, but it is front-loaded with the core purpose and output summary before adding safety constraints. Some repetition around the provider-anonymity rule exists, but in a safety-critical tool that repetition is largely justified.

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?

With no output schema, the description carries the burden of explaining what will be returned, and it does so thoroughly: architecture components, dependencies, routes, reasoning, economics bands, risks, deployment sequence, and closing blocks. It is complete enough for an agent to know what to expect, though some parameter-level detail is left to the schema.

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 description coverage is 61%, between the high and low thresholds. The description does not explain individual parameters, but it does add cross-tool meaning by saying it 'takes the same business profile as assess_business' and by tying output behavior to verticals and regions. This is moderate added value, not full compensation for the undocumented 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 opens with a specific call condition: 'Call this whenever the user needs an architecture: which rails, in what order, with what dependencies.' It also differentiates from siblings by calling itself 'Architect step 2, and the richest tool on this server' and by naming compare_stack_scenarios as the variation-testing alternative.

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?

It explicitly states when to use the tool ('Call this whenever the user needs an architecture') and directs the agent to compare_stack_scenarios for variation testing. However, it does not explicitly say when not to use alternatives like assess_business or recommend_stack, leaving some selection inference to the agent.

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?