Crosswire - payment infrastructure pricing, coverage and stack design

Compare stack scenarios

compare_stack_scenarios

Read-onlyIdempotent

Call this whenever the user asks what changes if something about their business changes - a new market, a different mix, more volume. Architect step 3. Takes a base business profile plus up to four labelled variations (for example 'add US market', 'move to 60% crypto', 'double volume') and returns what changes: architecture deltas (components added and removed), economics deltas as BANDS, and risk deltas. Full designs are not repeated - only the differences against the base. Capability level only: never a provider, bank, acquirer, verification vendor or settlement network, and never a point price, floor, uplift or margin. 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.

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.
`variations`	Yes	Scenarios to compare against the base profile.
`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.
`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.

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

addedInput schema / properties / variations / items / properties / changes / 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 / variations / items / properties / changes / 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 / variations / items / properties / changes / 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"
+}

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

addedInput schema / properties / variations / items / properties / changes / 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 / variations / items / properties / changes / 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."

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.2/5.0

Behavior5/5

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

Even with readOnlyHint and idempotentHint already protecting the safety profile, the description adds essential response behavior: economics always as BANDS, provider/bank/acquirer names never disclosed, results relayed as written, and no floors/uplifts/margins. The 'capability level only' constraint is repeated multiple times, which is valuable for an output-sensitive tool.

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

Conciseness3/5

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

Front-loaded and logically ordered, but long: provider-anonymity and capability-level-only constraints are stated at least twice in different phrasings. The repetition is likely deliberate for safety, yet it keeps this from being a tightly edited description.

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 18-parameter tool with no output schema, the description explains what the returned deltas look like and imposes the critical output rules, so the agent knows how to use the result. It is thin on how to assemble the base profile versus each variation and on how this step relates to the 'Architect step 3' workflow.

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?

The description gives useful examples for variations (labels like 'add US market') and says 'base business profile plus up to four labelled variations', matching the schema's required variations. With 61% schema description coverage, most parameter meaning already lives in the schema; the description does not add semantic detail for the many remaining fields.

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?

Opens with an explicit trigger ('Call this whenever the user asks what changes...') and names the exact input shape (base profile plus up to four labelled variations) and output categories (architecture deltas, economics bands, risk deltas). 'Full designs are not repeated' differentiates it from full-design sibling tools even 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 when-to-use condition is explicit and includes concrete examples ('add US market', 'move to 60% crypto', 'double volume'). It does not name alternatives or state when not to use it, so it misses the exclusion half of ideal guidance.

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?