Crosswire - payment infrastructure pricing, coverage and stack design

Submit a Crosswire partner application

submit_partner_application

Idempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 14, 2026

TDQS

A4.5/5.0

Behavior4/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Crosswire - payment infrastructure pricing, coverage and stack design tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?