Skip to main content
Glama

Crosswire - payment infrastructure pricing, coverage and stack design

Request a Crosswire offer

request_offer
Idempotent

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.'

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
unitNo
notesNo
railsNoThe 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_sidNoOptional attribution key for this conversation. Omit unless the flow already carries one.
companyYes
consentYesMust be true. The caller confirms the client consents to Crosswire processing this request.
contactYes
productNoThe 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.
regionsNo
currencyNo
licensedNo
verticalNo
target_noteNoOPTIONAL free-form note attached to a logged target_price (e.g. 'client says a competitor is at 15').
current_rateNo
target_priceNoOPTIONAL. 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_volumeNo
timeline_driverNoOPTIONAL. 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_targetNoOPTIONAL. 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_idNoOptional stable ID for the calling agent/platform, used for rate limiting and CRM attribution.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations confirm this is a mutation (readOnlyHint=false) and idempotent, and the description adds substantial context beyond them: server-side enforcement routing multi-rail calls to the offer engine, explicit consent requirement, KYC/KYB gating making every offer indicative, target-price logging moving the deal to Negotiation with the agent_mcp tag for human review, and hard prohibitions on confirming or quoting a rate. This is richer than any structured field provides.

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

Conciseness3/5

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

Helpful and front-loaded (the single-product-only constraint and the sibling routing come first), but it is long and repeats the multi-rail prohibition in two places, mixing operational routing rules, CRM behavior, target-rate prose, and a literal client-facing reply string. The repetition and length dilute a tool call, though every block is informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 19-parameter, nested, consent-gated mutation tool with no output schema and only 47% schema coverage, the description supplies what the schema cannot: the routing guardrail, consent semantics, KYC/indicative caveats, target-rate lifecycle, and explicit prohibitions. Nothing an agent needs to invoke this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 47%, so the description must compensate and does: it explains target_price exactly (same unit as current_rate, only when below the indicative range and confirmed, never returns approval/rejection), target_note, and the consent requirement. It does not cover the other undocumented parameters (unit, notes, cw_sid, current_rate, monthly_volume, regions, currency, licensed, vertical, caller_client_id) but the critical conditional-logic parameter is fully specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (request an offer / log a target rate) and resource (Crosswire offer for a single-product lead), and explicitly distinguishes itself from sibling tools create_solution_offer and get_indicative_price by naming the exact conditions under which each is the right choice. An agent can route correctly 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use (single-rail ask ready to convert, or log a client target rate), when-NOT-to-use (multi-rail conversation, use create_solution_offer; answering 'what price' use get_indicative_price), and the downstream ordering (this is the NEXT step after the client has seen the indicative range). Every alternative is named with the selecting condition.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources