Indicative pricing, coverage and stack design for high-risk and crypto payment infrastructure.
Scored across 15 tools
The descriptions go to great lengths to route between tools (e.g. request_offer vs create_solution_offer is gated by single vs multi-rail, get_indicative_price is 'the only pricing tool', get_faq/search/fetch form an explicit entry-point + retrieval pair). The main residual confusion is the three overlapping architect tools (assess_business, design_stack, recommend_stack) plus list_solutions, all of which answer 'what should this business use', with boundaries that only the long prose clarifies.
Nearly everything follows a clean snake_case verb_noun pattern (ask_integration, assess_business, check_coverage, design_stack, create_solution_offer, submit_partner_application). Minor deviations are the bare verbs search and fetch and the 'get_' prefix only on get_faq/get_indicative_price, but nothing is chaotic or camelCase-mixed.
15 tools sits at the top of the comfortable band and is justified by a genuinely broad domain (discovery, coverage, pricing, multi-step architecture, offers, advisory, partner programme, integration Q&A). It is slightly heavy given the retrieval trio and the near-synonymous stack-design tools, but nothing feels gratuitous.
The surface covers the full journey from grounding (get_faq/search/fetch) through needs, architecture, scenario comparison, indicative pricing, coverage, integration detail, offers and advisory/partner conversion. Gaps are minor: no way to look up an existing offer or case status, and no explicit KYC/KYB initiation tool, though these are partly handled by the offer flow.
Call this for any question about HOW a Crosswire rail is integrated - webhooks, signatures, sandboxes, authentication, callbacks, retries, SDKs, API shape, testing, go-live steps. Every answer is read from indexed documentation: nothing is inferred, nothing is generalised from one provider to another, and nothing is recalled from your own training data. If the index does not cover the question the tool declines and returns a blocker to report - repeat the decline, do not fill the gap. Before an offer is accepted the answer is capability level only, with no provider, product, SDK or URL in it; after acceptance, with the client's case reference passed in case_reference, the answer names the providers on that case, quotes the documentation and cites it. A question about a provider that is not on the case gets the capability-level answer. NEVER paste, repeat or ask for an API key, secret, token or password here - credentials are refused and no record of them is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The integration question, in the client's own words. Never include a credential value. | |
| case_reference | No | The client's Crosswire offer/case reference (CW-OFR-YYYY-NNNN). Supplied only when the client has an accepted offer; anything unresolvable is answered pre-signature. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, idempotent, closed-world), but the description discloses much more: answers are strictly grounded in an index, it declines with a blocker rather than guessing, behaviour is gated on offer acceptance, and credentials are refused and never recorded. This is exactly the extra context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The trigger condition is front-loaded and most sentences carry distinct operational content. The triple-negative grounding sentence ('nothing is inferred, nothing is generalised... nothing is recalled') is slightly redundant with the earlier 'read from indexed documentation', which keeps it short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two fully documented parameters, no output schema and annotations covering safety, the description supplies everything else an agent needs: scope, grounding guarantees, decline semantics, the pre/post-signature gate, and the credential prohibition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning beyond the schema: it explains that passing case_reference post-acceptance unlocks provider names, quotes and citations, and that an unresolvable reference falls back to the pre-signature capability answer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('any question about HOW a Crosswire rail is integrated') and then enumerates the covered topic space (webhooks, signatures, sandboxes, auth, callbacks, retries, SDKs, API shape, testing, go-live). An agent can tell this apart from generic siblings like search or get_faq without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear when-to-use conditions, including the pre- vs post-offer-acceptance distinction and the rule for providers not on the case. However it never routes against the obvious siblings (search, fetch, get_faq), so an agent choosing between documentation lookup tools gets no explicit tie-breaker.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
Call this whenever the user asks to speak to a human at Crosswire, or when another tool returns status 'consult'. Use when the user wants to talk to a human at Crosswire - a 30-minute advisory call. Returns the booking link. Optionally capture the caller's intent for the CRM. Does NOT return pricing - for price questions use get_indicative_price.
| Name | Required | Description | Default |
|---|---|---|---|
| cw_sid | No | Attribution key, as with request_offer. | |
| intent | No | Optional short note about what the caller wants to discuss. | |
| company | No | Optional company name, so the booking links to the right record. | |
| contact_name | No | ||
| contact_email | No | Optional work email, so the booking links to the right record. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real value beyond them: what is actually returned (a booking link, not a booking) and an optional side effect (capturing caller intent for the CRM) — the latter sits in mild tension with readOnlyHint but is worded as optional and secondary to the read-style link retrieval, so it does not rise to a contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the trigger condition, but the first two sentences say the same thing twice ('Call this whenever the user asks to speak to a human at Crosswire' vs 'Use when the user wants to talk to a human at Crosswire'). That duplication wastes space without adding information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly states the return value (the booking link). All parameters are optional, triggers and exclusions are covered, and the sibling alternative is named. Only the ambiguous CRM-capture behavior is left under-explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so the schema largely documents the five parameters itself. The description only loosely gestures at them via 'capture the caller's intent' and 'so the booking links to the right record', adding no format or syntax guidance beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete verb and resource ('Returns the booking link' for 'a 30-minute advisory call') and explicitly names the sibling it is not (get_indicative_price). An agent can distinguish it from the other 14 tools without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives two explicit triggering conditions ('whenever the user asks to speak to a human' and 'when another tool returns status "consult"') plus a clear exclusion ('Does NOT return pricing - for price questions use get_indicative_price'). This is textbook when/when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | Region or country (e.g. 'Germany', 'US', 'Hong Kong', 'LATAM'). | |
| product | No | Optional 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. | |
| activity | No | What the entity does, e.g. 'fiat-crypto conversion for retail'. | |
| currency | No | Optional settlement currency (ISO 4217, e.g. 'EUR', 'USD', 'GBP'). Coverage states which currencies the rail is priced in. | |
| vertical | No | Optional 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_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. | |
| full_inventory | No | Default 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. |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
Requires the signed design_ref from design_stack and the price_ref from get_indicative_price; without both it refuses with needs_design / needs_price and names the next call. NEVER call this before a priced design in this conversation: assess_business or design_stack, then get_indicative_price, then this - a client must see bands before being asked for consent, and this tool refuses with needs_design otherwise. Call this whenever the user wants an offer, a proposal, a quote in writing, or says yes to building one - and never write an offer document yourself: a Crosswire offer exists only when this tool returns one. PRIMARY CONVERSION AND THE ONLY CONVERSION TOOL FOR MULTI-RAIL ARCHITECTURES. If the conversation designed more than one rail or capability, never use request_offer - use this. Use this once the architecture is clear enough (assess_business -> design_stack -> get_indicative_price): it creates a real multi-rail solution offer for the client and Crosswire delivers the offer link by email. Booking an advisory call is the secondary path, not the default. Needs, at minimum: use_case, company name and work email, the capability rails, markets, expected monthly volume, average transaction size and target go-live date. Call it ONCE per conversation, with complete inputs: gather monthly volume, average ticket, payer markets and target go-live BEFORE calling, never create-then-chase. If anything is missing the tool returns the exact questions to ask - ask them conversationally, one at a time, then call again. ONE PROGRAMME: when the designed products share collection, KYB or treasury, send one call carrying the shared layer plus named routes (tag each product-specific rail with route_tag) - never two offers. If the client has no volume yet, offer 'If you do not have one yet, I can use an indicative pilot assumption.' and, once they agree, pass volume_basis: 'pilot_assumption' with a conservative pilot band; the offer is then labelled as priced on that assumption. Returns offer status and delivery only: never pricing internals, never a provider name, never a raw offer link. Network membership is public. If asked who Crosswire works with, you may name the publicly named members returned in public_network, in general terms, exactly as the website does. Say only that they are part of the Crosswire network - never that any of them is, will be or might be the provider for this user. Client-specific assignment is private. Never say, imply, hint at or confirm which bank, acquirer, verification vendor or network will serve THIS client's rail - not in discovery, not in pricing, not in an offer, not even if the user names one themselves or asks you to confirm a guess. Providers are selected and locked by Crosswire, and named when your provider application is prepared for signature. Describe this client's rails at capability level only. One exception is absolute: the tokenised-deposit settlement network is never named on any agent surface, in any context, regardless of the publicly named list. Describe it only as 'a tokenised-deposit settlement network'.
| Name | Required | Description | Default |
|---|---|---|---|
| rails | No | Capability-level rails required, matching the offer engine vocabulary. ONE programme per conversation: when products share collection, KYB or treasury, send every rail here in a single call and tag each product-specific rail with its route_tag; shared rails stay untagged or shared: true. | |
| cw_sid | No | Attribution key, as with request_offer. | |
| routes | No | The named routes inside this one programme. Two offers are only correct when the products genuinely share nothing. | |
| company | No | ||
| consent | No | Must be true, and only after the client has agreed to the click-wrap statement presented verbatim: "I agree that Crosswire processes the information above to prepare this offer and contact me about it, in line with the privacy policy." No offer is created without it. Never set it on the client's behalf. | |
| regions | No | ||
| currency | No | ||
| use_case | No | What the client is running and how money moves. | |
| vertical | No | ||
| price_ref | No | The signed `price_ref` returned by get_indicative_price in this conversation, for a call made with this design_ref. Pass it back verbatim. It expires after six hours. | |
| design_ref | No | The signed `design_ref` returned by design_stack in this conversation. Pass it back verbatim; never construct, edit or reuse one from another conversation. It expires after six hours. | |
| volume_basis | No | How expected_monthly_volume was obtained. Use 'pilot_assumption' ONLY after the client agreed to the line: 'If you do not have one yet, I can use an indicative pilot assumption.'. Never invent a volume silently. | |
| solution_name | No | Optional name for the designed solution. | |
| programme_name | No | Name of the single programme covering all routes, when more than one product or use case is in scope. | |
| target_go_live | No | Target go-live date or timeframe (e.g. 2026-10-01 or 'Q4 2026'). Feeds the offer's implementation-target line, computed conservatively and never a commitment. | |
| timeline_driver | No | OPTIONAL. What is driving that timing, verbatim from the client (e.g. 'our current provider is exiting gambling', 'the contract ends in November'). Free text, never summarised into a category. | |
| timeline_target | No | OPTIONAL. The client's timing target from the register's go-live question, in their own words - a date, a range or 'no fixed date' (e.g. 'before December', '60 days', 'Q1'). Record what they said; never infer one and never state a timeline back to the client. | |
| pilot_band_low_eur | No | Low end of the stated conservative pilot band. | |
| pilot_band_high_eur | No | High end of the stated conservative pilot band. | |
| region_volume_split | No | Monthly volume already stated per region, e.g. { "US": 2000000, "Europe": 6000000 }. Whenever the client has given a split, pass it: it is carried into every rail's pricing and into the architecture. Never re-ask for anything already stated. | |
| current_cost_summary | No | ||
| expected_monthly_volume | No | ||
| average_transaction_size | No | ||
| expected_transaction_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false): it discloses refusal behaviour and error codes (needs_design / needs_price), the hard consent requirement, reference-token expiry (six hours), that it must be called once per conversation with complete inputs, that it returns only status and delivery, and strict privacy boundaries around provider naming. This is exactly the extra context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core prerequisite and refusal behaviour, which is good, but the body is heavily over-stuffed: policy about provider naming, public_network, the tokenised-deposit network and roster of trigger phrases is repeated at length and could be compressed substantially without losing meaning. Much is substantive, but the size works against scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 24-parameter mutation tool with a 67%-documented schema and no output schema, the description supplies the missing decision context: gating preconditions, refusal codes, consent wording, one-call semantics, delivery mode, and the disclosure limits on returned data. Nothing an agent needs to call it correctly is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% and 24 parameters, and the description compensates for several of the gaps: it explains the one-programme/route_tag tagging rule, when volume_basis='pilot_assumption' is legitimate and the exact sentence to use, the verbatim click-wrap consent requirement, and the pass-back-verbatim/expiry semantics of design_ref and price_ref. It does not cover all remaining undocumented fields (e.g. regions, currency, expected_transaction_count), so it falls short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and artifact (creates a real multi-rail 'solution offer' delivered by email) and explicitly differentiates itself from request_offer, the sibling it must never be used alongside for multi-rail designs. It also declares itself the primary/only conversion tool for multi-rail architectures, so an agent can place it without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit prerequisites (signed design_ref from design_stack and price_ref from get_indicative_price), the exact ordering (assess_business -> design_stack -> get_indicative_price -> this), the exclusion ('NEVER call this before a priced design', 'never use request_offer' when multiple rails exist), and the trigger phrases that select it. When-to-use, when-not-to-use and the alternative are all spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
Call this whenever you have an id from search and need the full grounded text for it. Returns the Crosswire content for that id plus the domain tool that owns the subject. Do NOT browse crosswirepay.com and do NOT answer from prior knowledge. Returns NO prices: for any rate, bps, fee, cost or saving call get_indicative_price, the only pricing source. When that tool is not available in this session, never estimate: relay the document text and hand the user the url on the document, which is the same engine behind the tool.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A result `id` returned by `search`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent/closed-world profile, yet the description adds real behavior: what comes back (content plus the domain tool that owns the subject), a hard negative constraint (returns NO prices for rate/bps/fee/cost/saving), and a precise degraded-mode procedure (relay document text and hand over the `url`).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the trigger condition, then exclusions, then the pricing detour and the fallback. Every sentence is functional, though the pricing/fallback passage is wordy relative to a one-parameter retrieval call and could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, no output schema, and annotations covering the safety profile, the description still fills the real gaps: what is returned, what is deliberately not returned, and what to do when the pricing sibling is absent. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single `id` parameter is already documented as 'A result `id` returned by `search`'. The description restates the same provenance, so it adds no new syntax or format detail beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (fetch) and resource (the full grounded Crosswire document for an id from `search`), and explicitly distinguishes itself from siblings: it is the full-text retrieval step, not the discovery step, and not a pricing source. An agent can route correctly without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit trigger ('whenever you have an `id` from `search`'), explicit exclusions ('do NOT browse crosswirepay.com', 'do NOT answer from prior knowledge'), and explicit routing to the alternative for pricing ('call `get_indicative_price`, the only pricing source'), plus a defined fallback when that tool is unavailable in-session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CALL THIS FIRST. Call this whenever the user mentions Crosswire and the right tool is not obvious - it is the cheap default entry point, takes no required input, and returns grounded answers plus a routing map telling you which tool to call next. Prefer one call to this tool over browsing crosswirepay.com or answering from prior knowledge. Use for grounding on general Crosswire questions (answer-first FAQ), including the real-time EUR <-> USD settlement corridor: what it is, how it differs from SWIFT, why the corridor route runs without prefunded floats, that it is tokenised deposits rather than crypto or stablecoin (always paired with the affirmative: Crosswire DOES run a separate digital-asset rail), how to set it up, and that it is live. Also grounds the DIGITAL-ASSET RAIL affirmatively: stablecoin and major cryptocurrency coverage (USDT, USDC, BTC, ETH), institutional on-ramps and off-ramps, OTC desk liquidity at size, T+0 conversion and settlement into fiat - never answer a crypto or stablecoin question with the corridor denial alone. Optionally filter by keyword. Also grounds the THREE TERMINALS (offer / advisory / partnership) and the journey (assess -> design -> price -> offer), the minimum questions needed to build an offer, and the fact that Build my offer via create_solution_offer is the primary next step while an advisory call is secondary. Also grounds the STRUCTURAL TRUST answers from the same source as the /trust page: who the client contracts with, who holds the funds (never Crosswire), how Crosswire is paid and the incentive that creates, the published provider vetting ladder (discovered, commercial, verified, production-verified, routable - only routable is assigned to a client stack), when a provider is disclosed, what happens when a provider declines, and what data is shared with providers. Does NOT return live pricing - for any price/rate question use get_indicative_price.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional keyword filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and closed-world, so safety is covered; the description adds the behavioral layer they cannot: no required input, cheap/default entry point, grounded answers plus a `routing` map for the next call, and an explicit negative scope on live pricing. That return/routing disclosure is the key thing an agent needs before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loading 'CALL THIS FIRST' and the negative pricing scope are well placed, but the middle is a very long enumerated inventory of every FAQ topic (corridor details, terminals, trust answers, provider ladder) that reads as prompt-stuffing rather than routing information. The enumeration is partly useful for scoping grounding coverage, but it is far longer than needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of describing returns, and it does: grounded answers plus a `routing` map. It also states the negative boundary (no live pricing) and confirms no required input, leaving no significant operational gap for calling it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One optional parameter with 100% schema description coverage, so the schema already carries the meaning; the description only restates it as 'Optionally filter by keyword' without adding syntax, matching behavior, or defaults. Baseline 3 is appropriate when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (grounding/FAQ answers over Crosswire) and positions itself as the default entry point with a `routing` map for next-tool selection. It explicitly separates itself from `get_indicative_price` and from browsing crosswirepay.com, so an agent can distinguish it from siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('whenever the user mentions Crosswire and the right tool is not obvious'), when-not ('Does NOT return live pricing - for any price/rate question use `get_indicative_price`'), and names the alternatives to prefer (one call here instead of browsing or answering from prior knowledge). Nothing about selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this whenever any price, rate, bps, fee, spread, cost, discount or comparison is mentioned - before saying any number. THE ONLY PRICING TOOL. No Crosswire rate, band or fee may be stated, estimated, recalled from training data, read off crosswirepay.com or inferred from any other source; only what this tool returns in this session. Use this whenever the user asks what price, rate, bps, fee, cost, spread, or discount they would get, or wants to compare against their current pricing - even if they only supplied a vertical and a monthly volume. Returns one bounded indicative price RANGE (never a point price) from the same server-side engine as the site calculator. Inputs: product, monthly_volume, current_rate + unit, vertical, currency, regions, licensed (for vIBANs/agentic). Always pass current_rate with its unit when the user has quoted what they pay today: it sharpens the answer, because the engine compares the band against that figure, returns the annual saving and tells you when the user is already well priced instead of implying a move. Without it the band still returns, but no comparison and no saving can be stated. Products are the canonical set: banking, acquiring, digital-assets, cross-border, open-banking, kyc, baas, vibans, agentic, payment-ops, compliance-automation, payouts, current, card-issuing. Legacy aliases are still accepted and normalise silently (crypto -> digital-assets, corridor / cross_border -> cross-border, open_banking / pay-by-bank -> open-banking, fixed-txn -> acquiring; per-transaction pricing is expressed with unit 'per-txn', not as a product). Always relay the canonical value back to the user. Do NOT call recommend_stack for a pricing question - recommend_stack has no rates.
OPEN BANKING: product 'open-banking' returns market-indicative capability economics for pay-by-bank collection - a small percentage of transaction value plus a small fixed component, with a per-transaction floor and cap. Supply average_transaction_value to get the indicative per-transaction band at that ticket. Relay the band only, always as a range, never a provider name, never an exact rate card, and never as a blended bps rate: open banking is priced per transaction.
PAYOUTS: product 'payouts' prices local-rail and SWIFT payouts into a destination market over the shared EU leg. Pass destination and average_transaction_value. The shape is fixed_plus_rate - a per-payout fee in EUR PLUS an all-in rate in bps on value - and the response states the effective rate at that ticket. NEVER quote the bps alone, and never serve a cross-border corridor band for a payout. While a route has no recorded band the tool returns status 'pricing_followup' with no missing_fields: say the destination is priced on request, offer request_offer, and do not estimate.
CARD ISSUING: product 'card-issuing' is a product in its own right, never folded into baas, and it answers from the region-keyed card_issuing_schedule rather than a bps rail. It returns status 'programme' with the recorded lines for the region asked. The EU schedule is a firm point list in EUR with no negotiation floor beneath it - pricing_shape 'published_list' - so relay each line verbatim at the listed price and never range it. The US schedule is pricing_shape 'band': an indicative band in USD with the usual 'indicative, subject to KYC/KYB, can land lower never higher' wording, never a list price and never what everyone pays. Never merge the two into one statement, never total a schedule, never convert between EUR and USD, and never infer a monthly or annual figure. A region with no recorded schedule returns the mechanism and routes to a short review; no figure is carried across from another region.
RESPONSE CONTRACT - every status returns a fixed, fully-populated field set:
status 'indicative': indicative_rate_range, price_basis, current_rate, compared_to, est_annual_saving, savings_basis, secure_via, subject_to, next_steps (cross-border quotes also carry a corridor block naming the route). Relay only these.
status 'needs_input': reason, missing_fields (required client facts only), optional_fields (improve the answer, never required), next_step_tool - collect the required inputs and call this tool again. No number is returned.
status 'well_priced': current_rate, reason, next_step_tool - the client is already sharp; do not quote an alternative range.
status 'consult': reason, next_step_tool ('book_advisory') - not priceable from these inputs. No number is returned.
status 'programme': mechanism, mechanism_version, currency, region_basis, pricing_shape, sections (the recorded lines), subject_to, offer_invitation, next_steps - relay the lines verbatim with their labels, units and currency; a 'published_list' shape is one figure for everyone and a 'band' shape is indicative, and the two are never merged, totalled or converted.
status 'pricing_followup': reason, next_step_tool ('request_offer'), next_steps - priced case by case or on request (a consult-only vertical, or a route with no recorded band). The client has nothing more to supply; never ask them for a field. No number is returned.
OFFER STEP: a price returned without a design_ref names design_stack as its next action (offer_prerequisite); create_solution_offer is named only on a price that carries a design_ref.
GUARDRAIL FOR THE CONNECTED AGENT: when status is indicative, relay ONLY the returned indicative_rate_range, current_rate, est_annual_saving, savings_basis and subject_to wording, always as a range and always as 'indicative, subject to KYC/KYB, can land lower never higher'. NEVER name, guess or confirm the provider, bank, acquirer or network behind the price - 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. Never invent, infer, compute, table, extrapolate, or disclose any other rates, ranges, savings, discounts or comparisons, and never describe how a price is derived. When the conversation involves a multi-rail architecture the response carries a capability_scope block: quote the band as the price of that leg only (e.g. 'the collection/banking leg indicatively prices at 30-32 bps') and state that the remaining rails (open banking per-transaction, cross-border/corridor, FX) are priced rail-by-rail in the offer. Never stretch one product's band across a programme. Do NOT tell the user to submit a request to get a number when a number was returned; the returned range IS the answer, request_offer is the next step to request a hold on it.
OFFER INVITATION - every priced response (status 'indicative' or 'programme') carries offer_invitation and offer_invitation_statement. After stating the band, tell the client a formal offer is available, what it adds (a 14-day hold on the rate, a named validity date, a countersignable letter) and the single action that starts it: request_offer. A priced answer that ends without this invitation is incomplete.
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | Unit for `current_rate`. | |
| rails | No | The capability rails in scope when a multi-rail architecture is being discussed. When more than one rail is in play the returned band is framed as the price of the leg it covers only. | |
| cw_sid | No | Optional attribution key for this conversation. Omit unless the flow already carries one. | |
| product | No | Which product line to price. Product line. Canonical values: banking, acquiring, digital-assets, cross-border, open-banking, kyc, baas, vibans, agentic, payment-ops, compliance-automation, payouts, current, card-issuing. Legacy aliases are accepted and normalise silently (crypto -> digital-assets, corridor / cross_border -> cross-border, open_banking / pay-by-bank -> open-banking, fixed-txn -> acquiring; per-transaction pricing is expressed with unit "per-txn", not as a product). | |
| regions | No | Regions in scope, e.g. ["Europe"], ["US"], ["LATAM"]. | |
| currency | No | Pricing currency. Defaults to EUR (USD when regions = US only). | |
| licensed | No | For vIBANs and agentic ONLY: whether the client already holds the required licence for that product. False forces a consult. This is NOT the CASP question - EU crypto and digital-asset authorisation is `casp_status`, on its own four-value enum, and applies to every product. | |
| 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. | |
| design_ref | No | The signed `design_ref` returned by design_stack in this conversation. Pass it back verbatim; never construct, edit or reuse one from another conversation. It expires after six hours. | |
| 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. | |
| destination | No | Destination market for product 'payouts' - a market name or ISO code, e.g. 'Philippines', 'MX', 'Ghana'. A payout price is per destination: the rail, the classified band, the turnaround and the limits all follow it. | |
| current_rate | No | Client's current rate, matching `unit`. bps for banking/digital-assets, % for acquiring, per-txn fee where the pricing model is per transaction, per-check fee for kyc. | |
| monthly_volume | No | Monthly volume in the pricing currency (EUR/USD) for banking/acquiring/digital-assets/baas/vibans. For kyc, monthly verification count. | |
| average_transaction_value | No | Average transaction value in the pricing currency. Used by open-banking to express the indicative per-transaction band at that ticket. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint/idempotentHint/openWorldHint; the description goes far beyond, laying out the full response contract for all six statuses ('indicative', 'needs_input', 'well_priced', 'consult', 'programme', 'pricing_followup') with their exact field sets. It discloses hard behavioral constraints: never name the provider, never range a published_list price, never merge or total schedules, never quote bps alone for payouts, and the mandatory offer_invitation step. This is exceptionally rich disclosure for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded correctly: the directive to call before any number is stated in the first line, and the material is organised by product and by status. However the block is very long and repeats guardrail language (range-only, no provider names) across several sections, which is more than strict conciseness would demand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter, zero-required, multi-status tool with no output schema, the description carries the entire contract: what each status returns, what to relay, what never to state, and the next-step routing (design_stack vs create_solution_offer vs request_offer). Nothing an agent needs to call and interpret this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds substantial meaning beyond the schema: why current_rate sharpens the band and what the engine does with it (returns annual saving or 'well_priced'), the licensed-vs-casp_status distinction (casp_status is required for EU crypto answers), the semantics of average_transaction_value for open-banking, and product alias normalisation with instructions to relay the canonical value back.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (returns an indicative price band) and stakes out scope emphatically as 'THE ONLY PRICING TOOL'. It explicitly distinguishes itself from the closest sibling ('Do NOT call recommend_stack for a pricing question - recommend_stack has no rates') and enumerates the exact triggers (price, rate, bps, fee, spread, cost, discount, comparison). An agent can route to it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use triggers ('whenever any price, rate, bps, fee... is mentioned - before saying any number'), a when-not-to-use rule (recommend_stack), and conditional guidance per product (open-banking needs average_transaction_value; payouts needs destination; card-issuing answers from a region schedule). It also says exactly when to pass current_rate and what is lost without it. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this whenever the user asks what Crosswire offers, what products or rails exist, or what a solution includes - do not answer from crosswirepay.com or prior knowledge. Use when the user asks what Crosswire offers, which products/rails exist, or wants one-liners and coverage per solution, including the real-time EUR <-> USD settlement corridor (live). powered_by is capability level only: no provider, bank, acquirer or network is ever named. Optionally filter by category. Does NOT return prices - for any price/rate question use get_indicative_price. Does NOT recommend a fit - for fit use recommend_stack.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional filter for a single solution key. Product line. Canonical values: banking, acquiring, digital-assets, cross-border, open-banking, kyc, baas, vibans, agentic, payment-ops, compliance-automation, payouts, current, card-issuing. Legacy aliases are accepted and normalise silently (crypto -> digital-assets, corridor / cross_border -> cross-border, open_banking / pay-by-bank -> open-banking, fixed-txn -> acquiring; per-transaction pricing is expressed with unit "per-txn", not as a product). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent, and the description adds valuable behavioral constraints: no provider/bank/acquirer/network is ever named, the corridor is live, and the tool does not return prices or fit recommendations. This goes beyond the annotation baseline and clarifies important output boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description repeats the usage trigger twice ('whenever...' and 'Use when...'), which is redundant. It is front-loaded with the call condition and includes necessary exclusions, but could be tightened without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description explains what it returns (one-liners and coverage per solution), mentions the live corridor, and sets expectations about what it does not return. It covers the essentials an agent needs to invoke it correctly, though a bit of response-shape detail would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for category is very detailed (canonical values, legacy aliases, normalization), so schema coverage is 100%. The tool description only says 'Optionally filter by category', adding no new meaning beyond what the schema already provides, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool lists Crosswire solutions, products, rails, and per-solution coverage, using a specific verb and resource. It explicitly distinguishes itself from siblings by naming what it does not do (prices, fit), making it unambiguous which tool to select.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit triggers ('whenever the user asks what Crosswire offers...') and exclusions ('Does NOT return prices' -> use get_indicative_price; 'Does NOT recommend a fit' -> use recommend_stack). This leaves no doubt about when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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.
Call this whenever a genuinely single-rail ask is ready to convert, or to log a client target rate. SINGLE-PRODUCT ONLY. Use this ONLY for a genuinely single-rail ask - one product, no architecture design happened in this conversation. If the conversation designed an architecture with more than one rail or capability (assess_business / design_stack / recommend_stack / compare_stack_scenarios produced multi-rail output), the ONLY valid conversion tool is create_solution_offer; never select this tool in that state. The server enforces this: a multi-rail conversation calling request_offer is routed to the Crosswire offer engine automatically and returns an offer-being-prepared response, not a lead.
Otherwise: captures a single-product lead and secures an offer in the Crosswire CRM once the client wants to move forward (or where the engine returned a follow-up instead of an instant range), OR LOGS a client's desired target rate for the commercial team to review. Requires explicit consent. Reuses the same server-side pricing engine and lead pipeline as the site. Every offer is indicative, subject to KYC / KYB. Do NOT call this to answer 'what price would I get' - use get_indicative_price for that; this tool is the NEXT step after the client has seen the indicative range. Never quote a single blended rate in chat for a multi-rail programme: rail-level pricing lives on the offer page.
TARGET RATE HANDLING: If the client states a target price BELOW the returned indicative range (e.g. asks for 15 bps against an 18-20 opening), offer to log it, and on confirmation call this tool with target_price (their desired rate in the same unit as current_rate) and an optional target_note. This records the target as a counter on the CRM deal (stage=Negotiation, tagged agent_mcp) so the commercial team can review it under KYC/underwriting. You MUST NOT confirm the target is available, say whether it will be approved, quote below the indicative range yourself, or reveal or imply any internal pricing detail. Only capture the target for human review and reply: 'I have logged your target of {X} for the team to review as part of underwriting. This is not a confirmed rate.'
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | ||
| notes | No | ||
| rails | No | The capability rails in scope, if any architecture was designed. If more than one rail is present this tool routes the submission to the Crosswire offer engine automatically - use create_solution_offer directly instead. | |
| cw_sid | No | Optional attribution key for this conversation. Omit unless the flow already carries one. | |
| company | Yes | ||
| consent | Yes | Must be true. The caller confirms the client consents to Crosswire processing this request. | |
| contact | Yes | ||
| product | No | The single rail in scope. Accepted: banking, acquiring, digital-assets (alias crypto), fixed-txn, kyc, baas, vibans, agentic, corridor (alias cross-border - the real-time EUR <-> USD settlement corridor), open_banking (aliases pay-by-bank, open-banking - account-to-account collection in EU/UK payer markets). Same accepted set as get_indicative_price. | |
| regions | No | ||
| currency | No | ||
| licensed | No | ||
| vertical | No | ||
| target_note | No | OPTIONAL free-form note attached to a logged target_price (e.g. 'client says a competitor is at 15'). | |
| current_rate | No | ||
| target_price | No | OPTIONAL. The client's desired target rate, in the same unit as `current_rate` (e.g. bps for banking/digital-assets). Set ONLY when the client has stated a target BELOW the indicative range and confirmed they want it logged. Logging a target moves the deal to Negotiation for commercial-team review; it is NEVER a confirmed rate. Do not populate to 'test' whether a rate is available - the tool never returns approval or rejection of a target. | |
| monthly_volume | No | ||
| timeline_driver | No | OPTIONAL. What is driving that timing, verbatim from the client (e.g. 'our current provider is exiting gambling', 'the contract ends in November'). Free text, never summarised into a category. | |
| timeline_target | No | OPTIONAL. The client's timing target from the register's go-live question, in their own words - a date, a range or 'no fixed date' (e.g. 'before December', '60 days', 'Q1'). Record what they said; never infer one and never state a timeline back to the client. | |
| caller_client_id | No | Optional stable ID for the calling agent/platform, used for rate limiting and CRM attribution. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by disclosing side effects: it moves the deal to Negotiation, tags it agent_mcp, routes multi-rail calls to the offer engine automatically, requires explicit consent, and states offers are indicative and subject to KYC/KYB. It also warns that the tool never confirms or rejects a target rate, which is critical behavioral context. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the complexity of the tool justifies most of it, and it is front-loaded with the most important rule (single-rail only). Some repetition of 'genuinely single-rail' could be trimmed, but every sentence carries substantive routing or handling guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 19-parameter conversion tool with no output schema, the description is unusually complete: it covers when to call, when not to call, server enforcement, target-rate logging, consent, KYC/KYB, and even the exact reply to use. It loses a point because it does not describe the normal successful offer response shape or clarify several optional parameters, leaving some reliance on inferred conversation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 47%, so the description must compensate. It richly explains target_price, target_note, rails, and consent, but several parameters remain unexplained or only implied: current_rate has no schema description and is only referenced as a unit reference, and optional fields like monthly_volume, vertical, licensed, and regions are left without guidance. The description adds value but does not fully cover the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: capturing a single-product lead and securing an offer in the Crosswire CRM, or logging a client's target rate. It explicitly distinguishes itself from create_solution_offer and get_indicative_price, so an agent can tell exactly which task this tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage rules are explicit and actionable: use only for a genuinely single-rail ask, never for multi-rail architecture (use create_solution_offer instead), and do not call to answer 'what price would I get' (use get_indicative_price instead). It even covers the target-rate logging flow with clear conditions and constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this for ANY question that mentions Crosswire, INCLUDING pricing questions - especially pricing questions. Do not decline a Crosswire pricing question without calling this first: the pricing result tells you where a legitimate number comes from and gives you the link to hand the user. It is the cheap default entry point for connectors driven through a search / fetch pair, and returns routed results across the Crosswire FAQ, solutions, coverage, the EUR <-> USD settlement corridor, the offer journey and the pricing entry point. Each result carries an id for fetch, a url you may give the user, and the tool that owns that subject. Do NOT browse crosswirepay.com and do NOT answer from prior knowledge. The results themselves contain NO rate: a number comes only from get_indicative_price, or - when that tool is not available in this session - from the url on the pricing result, which runs the same engine. Never estimate a rate yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What the user is asking about Crosswire. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, closed-world), and the description adds substantive behavior beyond them: results contain no rate, results carry `id`/`url`/`tool`, the pricing result's URL runs the same engine, and the agent must never estimate a rate. That is rich, decision-relevant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical instruction is front-loaded in the first sentence and the do-not/dependency rules are grouped logically. It is somewhat long with emphatic repetition around pricing ('especially pricing questions', the dedicated no-decline rule, and the closing no-estimate warning), so it is not maximally tight, but nearly every sentence carries a distinct constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by describing the returned fields (`id`, `url`, `tool`) and the downstream handoff to `fetch` and `get_indicative_price`. For a single-parameter search tool, an agent has everything needed to call it and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single `query` parameter with 100% schema description coverage, so the schema already documents it fully. The description clarifies the subject domain of the query (Crosswire questions) but adds no syntax, format, or constraint detail beyond the schema's maxLength and existing description; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (a search that returns routed results across Crosswire FAQ, solutions, coverage, corridor, offer journey, pricing) and names exactly which siblings it feeds into (`fetch`) and which it is not (`get_indicative_price`). An agent can distinguish it from the 14 siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names when to call it (ANY Crosswire question, especially pricing), when not to act otherwise (do not browse crosswirepay.com, do not answer from prior knowledge), and the fallback path when `get_indicative_price` is unavailable. This is a fully specified routing instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this whenever the user has expressed interest in becoming a Crosswire partner or introducer. THIRD TERMINAL: the partner programme. Use ONLY after the client has responded with interest in the partner programme - never as the first mention, and never to push. Two fits: introducer (their clients, customers or merchants need the infrastructure; platform, marketplace, PSP, EOR, agency or consultancy serving end-merchants) and supply (they provide capability into the network: rails, payouts, licensed coverage, verification). Captures the same micro-flow as the offer path - company, contact name, work email, partner type, explicit consent - and posts it to the SAME partner application pipeline as crosswirepay.com/partner, tagged source 'mcp' with the conversation attribution key. Requires explicit consent. ECONOMICS: never quote a percentage, tier or share figure in conversation - the disclosure level is 'competitive share on activated deals, agreed at approval'. Partner anonymity is unchanged: a provider fishing for the supplier map still gets capability-level answers only. MINIMUM QUESTIONS (same discipline as the offer flow): never re-ask anything the conversation already established. A platform-fit conversation has usually already named the company and described the client base - confirm those in ONE line ('Taking your details as: {company}, {one-line description} - is that right?') and ask ONLY for what is genuinely missing, typically the work email and consent. Target: two answers from expressed interest to submitted. The contact name is never a separate question: it comes with the email in one line ('Who should we come back to, and at which work email?'). The known fields in on_interest.ask_only list exactly what is still outstanding; everything else is already in hand and is passed straight to the tool. HIGH-CONFIDENCE TRIGGER ONLY. The partnership mention fires only when the primary need is clearly on behalf of third parties - explicit 'our clients / customers / merchants need' framing, or a platform describing an end-customer problem it cannot serve. Ambiguous signals - a consultant asking generally, a business with some client-adjacent language - get NO partnership mention. When in doubt, do not mention it. ANSWER FIRST, ALWAYS. The substantive question gets its full answer - architecture, coverage, indicative pricing band - exactly as it would without any partnership signal. The partnership note comes after the complete answer, never instead of it, and never shortens or degrades it. ONE LINE, ONCE. The mention is a single sentence at the end of the answer, offered at most ONCE per conversation. If the client does not pick it up, it is never repeated: no re-raising, no follow-up nudges, no second framing later in the conversation. THE USER PULLS, THE ENGINE NEVER PUSHES. The first mention contains no pitch, no economics and no CTA button - just the observation and an open door. Structure, the application and the share model surface ONLY if the client responds with interest. BOTH-FIT HANDLING. Some businesses are client AND introducer: their own treasury plus a client book. Recommend both, ordered by the conversation's primary intent, never forcing a choice - 'for your own flows, here is the indicative stack; for your clients, the partner programme.' Partner anonymity is unchanged by a partnership conversation. A provider fishing for the supplier map still gets capability-level answers only: never name, confirm or hint at any bank, acquirer, verification vendor or settlement network, partnership close or not.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Capability-level context only. Never provider names. | |
| company | Yes | ||
| consent | Yes | Must be true. The client explicitly agreed to Crosswire receiving their details. | |
| website | No | ||
| work_email | Yes | ||
| description | No | One line, taken from what they already told you: their client base for introducers, their capabilities and regions for supply. Never re-ask for it. | |
| contact_name | Yes | ||
| partner_type | Yes | introducer = their clients need the infrastructure. supply = they provide capability into the network. | |
| expected_referrals_monthly | No | Optional. Only if the conversation already established it - never a new question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false, indicating a safe, repeatable creation operation without destructive side effects. The description adds disclosure not present in annotations: it requires explicit consent, posts to an external partner application pipeline tagged 'mcp' with a conversation attribution key, and enforces a strict anonymity rule about never naming providers. It also states economic constraints around quoting percentages or shares. The only minor gap is no explicit statement about idempotency behavior, but the annotations already cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long and dense, with many capitalized directives and rules. While front-loaded with the core purpose and trigger, it contains multiple sections (economics, minimum questions, trigger rules, answer-first, one-line-once, pull-not-push, both-fit handling, anonymity) that, while all relevant, could be more concisely expressed. It is appropriately detailed for a complex conversational policy, but the structure is somewhat overwhelming.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—enforcing a strict conversational protocol, ensuring consent, maintaining anonymity, and handling two partner types—the description is thorough. It covers usage timing, trigger conditions, behavioral constraints, parameter guidance, and conversational flow. It leaves no gap about when and how to call it, and the absence of an output schema means no return-value explanation is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 56%, so some documentation is embedded in the schema (consent, partner_type enum, description, notes, expected_referrals_monthly). The description compensates by explaining what 'introducer' and 'supply' mean, the required consent, and clarifying that contact_name comes from the email in one line. It also defines the 'known' fields in on_interest.ask_only, giving semantic depth beyond the schema. With the schema handling some parameters and the description adding meaning, a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('submit_partner_application' / Crosswire partner application), names the two partner types ('introducer' and 'supply'), and defines them. It clearly distinguishes itself from sibling tools like create_solution_offer and request_offer by being the terminal step for the partner programme.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('THIRD TERMINAL: the partner programme', 'Use ONLY after the client has responded with interest - never as the first mention, and never to push'), and provides a high-confidence trigger rule. It also includes when-not-to-use conditions ('Ambiguous signals get NO partnership mention') and distinguishes the two partner-type fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_coverage1 field changedInput schema / properties / product / enumPrevious 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"
+]get_indicative_price2 fields changedInput schema / properties / product / descriptionPrevious value: -"Which product line to price. Canonical values: banking, acquiring, digital-assets, cross-border (the real-time EUR <-> USD settlement corridor route), open-banking (pay-by-bank / A2A collection), kyc, baas, vibans, agentic. Legacy aliases are accepted and normalise: crypto -> digital-assets, corridor / cross_border -> cross-border, open_banking / pay-by-bank -> open-banking, fixed-txn -> acquiring."New value: +"Which product line to price. Product line. Canonical values: banking, acquiring, digital-assets, cross-border, open-banking, kyc, baas, vibans, agentic, payment-ops, compliance-automation, payouts, current, card-issuing. Legacy aliases are accepted and normalise silently (crypto -> digital-assets, corridor / cross_border -> cross-border, open_banking / pay-by-bank -> open-banking, fixed-txn -> acquiring; per-transaction pricing is expressed with unit \"per-txn\", not as a product)."Input schema / properties / product / enumPrevious 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"
+]list_solutions2 fields changedInput schema / properties / category / descriptionPrevious value: -"Optional filter for a single solution key. Product line. Canonical values: banking, acquiring, digital-assets, cross-border, open-banking, kyc, baas, vibans, agentic, payment-ops, compliance-automation, payouts, current. Legacy aliases are accepted and normalise silently (crypto -> digital-assets, corridor / cross_border -> cross-border, open_banking / pay-by-bank -> open-banking, fixed-txn -> acquiring; per-transaction pricing is expressed with unit \"per-txn\", not as a product)."New value: +"Optional filter for a single solution key. Product line. Canonical values: banking, acquiring, digital-assets, cross-border, open-banking, kyc, baas, vibans, agentic, payment-ops, compliance-automation, payouts, current, card-issuing. Legacy aliases are accepted and normalise silently (crypto -> digital-assets, corridor / cross_border -> cross-border, open_banking / pay-by-bank -> open-banking, fixed-txn -> acquiring; per-transaction pricing is expressed with unit \"per-txn\", not as a product)."Input schema / properties / category / enumPrevious 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"
+]request_offer1 field changedInput schema / properties / product / enumPrevious 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"
+]assess_business3 fields changedInput schema / properties / activityAdded value: +{
+ "description": "What the entity does, e.g. 'fiat-crypto conversion for retail'.",
+ "maxLength": 160,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / end_user_typeAdded value: +{
+ "description": "Who its end users are, e.g. 'EEA retail customers'.",
+ "maxLength": 120,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / registrationsAdded 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"
+}check_coverage4 fields changedInput schema / properties / activityAdded value: +{
+ "description": "What the entity does, e.g. 'fiat-crypto conversion for retail'.",
+ "maxLength": 160,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / end_user_typeAdded value: +{
+ "description": "Who its end users are, e.g. 'EEA retail customers'.",
+ "maxLength": 120,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / incorporationAdded 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"
+}Input schema / properties / registrationsAdded 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"
+}compare_stack_scenarios6 fields changedInput schema / properties / activityAdded value: +{
+ "description": "What the entity does, e.g. 'fiat-crypto conversion for retail'.",
+ "maxLength": 160,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / end_user_typeAdded value: +{
+ "description": "Who its end users are, e.g. 'EEA retail customers'.",
+ "maxLength": 120,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / registrationsAdded 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"
+}Input schema / properties / variations / items / properties / changes / properties / activityAdded value: +{
+ "description": "What the entity does, e.g. 'fiat-crypto conversion for retail'.",
+ "maxLength": 160,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / variations / items / properties / changes / properties / end_user_typeAdded value: +{
+ "description": "Who its end users are, e.g. 'EEA retail customers'.",
+ "maxLength": 120,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / variations / items / properties / changes / properties / registrationsAdded 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"
+}design_stack3 fields changedInput schema / properties / activityAdded value: +{
+ "description": "What the entity does, e.g. 'fiat-crypto conversion for retail'.",
+ "maxLength": 160,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / end_user_typeAdded value: +{
+ "description": "Who its end users are, e.g. 'EEA retail customers'.",
+ "maxLength": 120,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / registrationsAdded 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"
+}recommend_stack4 fields changedInput schema / properties / activityAdded value: +{
+ "description": "What the entity does, e.g. 'fiat-crypto conversion for retail'.",
+ "maxLength": 160,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / end_user_typeAdded value: +{
+ "description": "Who its end users are, e.g. 'EEA retail customers'.",
+ "maxLength": 120,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / incorporationAdded 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"
+}Input schema / properties / registrationsAdded 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"
+}assess_business2 fields changedInput schema / properties / casp_statusAdded 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"
+}Input schema / properties / vertical / descriptionPrevious 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."compare_stack_scenarios4 fields changedInput schema / properties / casp_statusAdded 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"
+}Input schema / properties / variations / items / properties / changes / properties / casp_statusAdded 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"
+}Input schema / properties / variations / items / properties / changes / properties / vertical / descriptionPrevious 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."Input schema / properties / vertical / descriptionPrevious 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."design_stack2 fields changedInput schema / properties / casp_statusAdded 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"
+}Input schema / properties / vertical / descriptionPrevious 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."get_indicative_price5 fields changedInput schema / properties / casp_statusAdded 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"
+}Input schema / properties / licensed / descriptionPrevious value: -"For vIBANs and agentic: whether the client already holds the required licence. False forces a consult."New value: +"For vIBANs and agentic ONLY: whether the client already holds the required licence for that product. False forces a consult. This is NOT the CASP question - EU crypto and digital-asset authorisation is `casp_status`, on its own four-value enum, and applies to every product."Input schema / properties / vertical / descriptionPrevious value: -"Business vertical (e.g. e-commerce, crypto, iGaming, adult, forex, marketplace). The engine decides whether an instant range or a follow-up applies."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."Input schema / properties / vertical / enumAdded value: +[
+ "e-commerce",
+ "saas",
+ "standard",
+ "marketplace",
+ "banking",
+ "crypto",
+ "igaming",
+ "adult",
+ "forex",
+ "other"
+]Input schema / properties / vertical / maxLengthRemoved value: -60recommend_stack6 fields changedInput schema / properties / casp_status / descriptionPrevious 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."Input schema / properties / casp_status / enumPrevious value: -[
- "authorised",
- "in_application",
- "not_required",
- "none"
-]New value: +[
+ "authorised",
+ "in_application",
+ "not_required",
+ "none",
+ "other"
+]Input schema / properties / vertical / descriptionPrevious 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."Input schema / properties / vertical / enumAdded value: +[
+ "e-commerce",
+ "saas",
+ "standard",
+ "marketplace",
+ "banking",
+ "crypto",
+ "igaming",
+ "adult",
+ "forex",
+ "other"
+]Input schema / properties / vertical / maxLengthRemoved value: -60Input schema / properties / vertical / minLengthRemoved value: -2ask_integrationassess_businessbook_advisorycheck_coveragecompare_stack_scenarioscreate_solution_offerdesign_stackfetchget_faqget_indicative_pricelist_solutionsrecommend_stackrequest_offersearchsubmit_partner_applicationPayment infrastructure for AI agents: spending rules, approval flows, single-use virtual cards.
Payment identity intelligence for AI agents.
Private stablecoin payments for people and AI agents, hosted or local with spending limits.
Counterparty due-diligence infrastructure: OFAC screening, on-chain risk, signed verdicts.
Add one secure layer between your agents and this server.
