Crosswire - payment infrastructure pricing, coverage and stack design

Assess a business

assess_business

Read-onlyIdempotent

Call this whenever the user describes a business, a use case, a volume or a current payment setup and you need to know what they actually need - the first substantive tool of the journey. Architect step 1. Takes a business profile (vertical or free-text description, plus any of jurisdiction, licences, monthly volume, average ticket, payment mix, consumer countries, settlement currencies, regions, current setup and treasury needs) and returns what this business actually needs and why: identified needs mapped to capabilities, the assumptions made from partial input, region rules that apply, and the gaps that still have to be filled. Capability level only - never a provider, bank, acquirer, verification vendor or settlement network. Returns no price. Follow with design_stack for the full architecture. 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.
`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.

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

Behavior5/5

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

The annotations already mark the tool readOnly and idempotent, and the description adds substantial behavioral context beyond that: provider anonymity constraints, capability-level-only output, economic bands versus point prices, risk flags as generic readiness items, and the instruction to relay output as written. It also discloses that assumptions are made from partial input and that gaps are returned.

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 the tool is complex and carries critical guardrails around provider anonymity, pricing bands, and sequencing. The opening sentence is front-loaded and action-oriented. Some repetition of 'never name a provider' occurs, but it is a safety-critical constraint and is distributed where relevant, so the length is largely justified.

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?

For a 17-parameter tool with no output schema, the description is remarkably complete: it specifies what the tool returns (needs mapped to capabilities, assumptions, region rules, gaps), what it does not return (price, provider identities), how the output should be relayed, and what to do next (design_stack). An agent has enough context to invoke the tool correctly and interpret its response safely.

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 coverage is 59%, and the description partially compensates by listing the main profile dimensions (vertical or free-text, jurisdiction, licences, volume, ticket, payment mix, consumer countries, currencies, regions, current setup, treasury needs). However, some parameters such as end_user_type, target_go_live, and registrations are not mentioned, and the description does not add detail beyond naming the categories, leaving the schema to carry much of the parameter-level meaning.

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 specific verb ('assess'), a clear resource (a business profile), and a concrete result: what the business needs and why, mapped to capabilities. It also distinguishes itself from siblings by positioning itself as 'Architect step 1' and the 'first substantive tool of the journey', with design_stack named as the next step.

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 trigger condition is explicit: call it whenever the user describes a business, use case, volume, or payment setup and you need to know what they need. It also gives exclusion guidance ('never a provider', 'returns no price') and names the follow-up tool, design_stack. It does not explicitly enumerate sibling alternatives, but the role and boundary are clear enough.

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?