Crosswire - payment infrastructure pricing, coverage and stack design

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.

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

Annotations only cover safety/idempotency (readOnlyHint, idempotentHint, openWorldHint=false), so the description must carry the rest — and it does heavily: capability-level-only output, no price returned, provider/bank/acquirer anonymity enforced, economics as bands with no averaging/interpolation, and risk flags framed as generic readiness items rather than approval odds. This is unusually rich disclosure of output semantics and policy constraints.

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 purpose, trigger, and return content before the lengthy constraint block. The provider-anonymity and economics-band rules are restated in several forms ('never name, guess, hint at or confirm a provider...' and the closing provider/economics paragraph), adding redundancy, but each sentence is actionable for an agent.

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 13 parameters, nested objects, no required fields and no output schema, the description does the needed work: explains what is returned, how partial input is handled (assumptions are surfaced), and the downstream handoff to design_stack. It does not indicate defaults or expected handling for empty/partial optional objects, which is the only real gap.

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 only 46% across 13 nested parameters, so the description compensates by enumerating nearly all accepted inputs ('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'). It also echoes the schema's vertical-vs-description dependency rule. It stops short of adding format/syntax meaning (e.g. currency units, percentage semantics) beyond parameter names.

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 ('takes a business profile ... returns what this business actually needs and why') and enumerates the concrete outputs (identified needs mapped to capabilities, assumptions, region rules, gaps). It also positions itself in the sibling set as 'the first substantive tool of the journey' and names design_stack as the next step, so an agent can distinguish it from recommend_stack or design_stack.

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 an explicit trigger — 'call this whenever the user describes a business, a use case, a volume or a current payment setup' — and names the follow-on tool (design_stack for the full architecture). It does not state when *not* to use it versus list_solutions or compare_stack_scenarios, but the context is otherwise clear.

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

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.

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

Annotations already declare readOnlyHint and idempotentHint, but the description goes far beyond them: it discloses guardrails (never names a provider, bank, acquirer or network), how unconfirmed verticals are phrased, how missing market rows are answered, and that results come from a pinned export rather than prose. This is unusually rich behavioral context 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?

The first sentence front-loads well and PAYOUTS/OPEN BANKING/SCOPE headers help, but the description is a wall of dense prose with repeated rules (the 'never name a provider/network' guardrail appears at least three times) and buries the practically important flag semantics far from the top. Many sentences do not earn their place.

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, multi-family tool with no output schema, it covers the main answer shapes (regional, payout, open banking, corridor, scoped inventory) and failure modes (unrecorded rows, unconfirmed verticals). Completeness is high; the tangled prose makes it harder than it needs to be to confirm the answer contract.

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, and the description adds real meaning on top: it explains that legacy aliases normalise, that 'cross-border' always returns the EUR<->USD corridor block, and how vertical/currency change the shape of the answer. The gating logic for full_inventory is meaningful, though some of the enum detail merely restates the schema.

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 (check) and resource (Crosswire coverage) and enumerates exactly what it answers: where Crosswire operates, whether a country/region is served, what capabilities exist in a market. It is clearly distinguishable from siblings such as get_indicative_price, which it explicitly delegates pricing questions to.

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 an explicit trigger ('call this whenever the user asks...') , an explicit prohibition ('never answer coverage from the website or prior knowledge'), and names the alternative for out-of-scope questions ('Does NOT return pricing - for any price/rate question use get_indicative_price'). It even scopes the full_inventory flag to an explicit user request.

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

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

Annotations only cover safety/provenance (readOnly, idempotent, closed-world). The description adds real behavioral context an agent cannot get elsewhere: outputs are economics BANDS not point prices, deltas are relative to a base profile, results must be relayed as written, and risk flags are generic readiness items rather than provider appetite. This is exactly the extra context the dimension rewards.

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 and purpose are correctly front-loaded, but the body is padded with redundant compliance repetition - the prohibition on naming providers/banks/acquirers appears twice in near-identical wording, as does the bands-not-prices rule. Roughly half the text is reiteration rather than new 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 14-parameter tool with nested objects and no output schema, the description does describe the return contents (architecture deltas, economics bands, risk deltas, sequence), which is valuable. However, the parameter layer is only half-covered and the description never explains base-vs-variation inheritance beyond repeating the schema note, leaving real gaps.

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 50%, so some compensation is needed. The description supplies useful examples of variation labels ('add US market', 'move to 60% crypto', 'double volume') and confirms the 'up to four' variation cap, but it does not clarify major base-profile parameters such as payment_mix, current_setup, or monthly_volume_eur, and it restates rather than extends the schema's 'only fields that differ' note.

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 ('compare ... scenarios ... returns what changes') and clearly scopes the output to deltas only ('Full designs are not repeated - only the differences against the base'). This implicitly separates it from design_stack, though no sibling is named outright.

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 a concrete, observable trigger ('Call this whenever the user asks what changes if something about their business changes - a new market, a different mix, more volume') plus a workflow position ('Architect step 3'). No when-not condition or named alternative is offered, so it stops short of a 5.

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

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.

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

Annotations already declare readOnly, idempotent, closed-world, so the safety profile is covered. The description adds substantial non-obvious behavior: two fixed closing blocks always returned, consult status replaces architecture for certain inputs, and heavy output content restrictions (no provider names, bands not point prices).

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 tool behavior ends early; the remainder is a repetitive wall of output-governance rules (never name a provider, bands never point prices, never state floors, etc.) that restate the same prohibition multiple ways. The description is dominated by compliance rules rather than tool selection 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?

No output schema exists and the description does enumerate the major return sections (components, routes, reasoning, economics bands, risks, sequence, two closing blocks), which fills some of that gap. But parameter documentation remains thin for a 14-param tool and missing when-to-use against recommend_stack.

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 50%, so half the 14 parameters rely on the description. It only states that it takes 'the same business profile as assess_business' and names economics bands, without explaining regions, licences, engagement_ref semantics, or treasury_needs beyond what the schema already says. Adequate but far from full compensation for the coverage 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?

States a specific verb and resource: it produces an architecture (rails, order, dependencies) from a business profile. It distinguishes itself from assess_business (step 1) and compare_stack_scenarios (variation testing), but the self-congratulatory 'richest tool on this server' is unhelpful filler.

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 positions itself as 'architect step 2' after assess_business, and names compare_stack_scenarios as the variation-testing alternative. Also routes consult-tier verticals and prohibited region combos to a consult status. Lacks when-NOT-to-use for recommend_stack, which overlaps in the same family.

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

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.

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.

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

Annotations cover the safety profile (readOnly, idempotent, closed-world), but the description adds far more: it always returns a bounded range never a point price, enumerates all five status outcomes with their fixed field sets, and imposes provider-confidentiality and range-only guardrails. This is rich behavioral disclosure well beyond the 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?

Front-loaded with the key instruction and organised under headings, but it is long and frequently repetitive — canonical products and aliases are stated twice, and the guardrail/offer material is restated. Some length is justified by 13 params and many statuses, yet redundancy costs it.

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 defining the exact response field set for every status, the pricing model per product, and the offer-invitation obligation. An agent has everything needed to call it and relay results 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 100%, so the baseline is 3, but the description adds cross-field meaning: always pass current_rate with its matching unit to unlock the comparison and annual saving, destination and average_transaction_value drive payouts/open-banking, and legacy product aliases normalise silently. It explains interplay the schema alone does not.

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 — returns an 'indicative price RANGE' from a pricing engine — and explicitly differentiates itself as 'THE ONLY PRICING TOOL', naming the sibling it is not (recommend_stack has no rates). An agent can tell immediately what this does versus its siblings.

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 trigger conditions ('call this whenever any price, rate, bps, fee... is mentioned - before saying any number'), when-not rules ('Do NOT call recommend_stack for a pricing question'), and routes to the correct alternatives (request_offer, book_advisory) per status. 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.

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description's real contribution is the disclosure that `powered_by` is capability-level only and no provider/bank/acquirer is ever named, plus the note that it never returns prices. That is genuinely useful context about result semantics. It falls short of 5 because it says nothing about result size, pagination, or ordering of the solution list.

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 well — trigger first, then capability notes, then exclusions — but the opening two sentences are near-duplicates ('Call this whenever the user asks what Crosswire offers, what products or rails exist' vs 'Use when the user asks what Crosswire offers, which products/rails exist'). That repetition consumes space without adding information, which is the main structural flaw.

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 describing returns, and it does so adequately: enumerated solutions with one-liners and coverage, an explicit note that prices and fit recommendations are absent, and a clarification of the `powered_by` field. It is not fully complete only because it omits anything about result volume or shape.

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 100%: the single `category` parameter already documents every canonical value and the legacy alias normalization rules in detail. The description only echoes 'Optionally filter by category', adding no meaning beyond the schema, so the baseline of 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?

The description states a specific resource ('Crosswire solutions') and the exact granularity returned — one-liners and coverage per solution — which tells an agent precisely what enumeration it gets. It also names the sibling tools it is not (get_indicative_price, recommend_stack), so it is distinguishable from the surrounding catalog without opening a 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 explicit triggers ('user asks what Crosswire offers, what products or rails exist, or what a solution includes') plus hard exclusions with redirects: no prices, use get_indicative_price; no fit, use recommend_stack. It even forbids answering from crosswirepay.com or prior knowledge, which is exactly the when-not-to-use guidance agents need.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds substantial behavior beyond that: supplied inputs are echoed in `fields` and never re-asked, sensitive verticals yield a consult, EU+US scope triggers the EUR<->USD settlement corridor, and no provider/bank/acquirer is ever named. It also states clearly what is NOT returned (pricing, rates, bps, fees, savings).

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 front-loaded rule is good, but the opening two sentences restate the same condition ('which Crosswire products or rails fit their setup') three times, which is pure redundancy. The rest of the content earns its place, but the definition would be tighter without the repetition.

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 10-parameter tool with no output schema, the description covers the return shape (rails plus rationale plus source need), consult fallbacks, and the corridor addition. It is nearly complete, though the roles of `regions`, `target_launch`, and `monthly_volume` in shaping the recommendation are left implicit.

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 baseline is already 3, and the description adds genuine meaning on top: `description` is preferred over structured inputs, `optimise_for` re-sequences the same architecture without touching pricing, and `engagement_ref` is only honored when valid/unexpired/unrevoked. It does not explain `regions`, `target_launch`, or `monthly_volume` semantics, keeping it 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 resource ('Recommend a Crosswire stack') and immediately scopes it against its closest sibling by naming `get_indicative_price` as the wrong tool for pricing questions. An agent can distinguish this from `design_stack` or `compare_stack_scenarios` on the basis of the recommendation-vs-pricing axis.

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 an explicit rule for both directions: use when the user asks which products/rails fit their setup, and use `get_indicative_price` instead for any price/rate/cost/fee question. It also carves out sensitive verticals (forex, adult) that return a consult rather than a firm stack, which is real routing guidance.

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

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.

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.

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.

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.

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.

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.

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.

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.