US bank wire fees, cutoff times and the cheapest ways to send money to Mexico, India, Philippines.
Scored across 4 tools
Each tool has a clearly distinct role: comparing multiple banks, detailing one bank, ranking remittance providers, and checking cutoff times. The compare-vs-get distinction is explicit, and the transfer-provider tool is clearly separated from bank wire fee tools.
All names use snake_case with verb-led phrasing, and three follow a tight verb_noun pattern. find_cheapest_way_to_send_money is longer and less noun-centric, but it remains readable and consistent enough.
Four tools are well-scoped for a focused bank-wire and transfer-cost data server. Each tool covers a distinct workflow, with no filler or obviously missing companion tool.
The surface covers multi-bank comparison, single-bank fee detail, remittance-provider costs, and Fedwire cutoff/holiday logic. Minor gaps exist, such as no standalone exchange-rate lookup or historical fee data, but the core domain is well covered.
Ranks US banks from lowest to highest published fee for one kind of wire (outgoing or incoming, domestic or international, in dollars or foreign currency), for personal or business accounts. Pass 2 to 17 banks, or none to rank every bank covered. Banks that do not publish the fee or do not offer the wire are listed last with the reason.
| Name | Required | Description | Default |
|---|---|---|---|
| banks | No | Bank names to compare, e.g. ["Chase","Wells Fargo","Ally"]. Omit to rank all covered banks. | |
| wire_type | Yes | Which fee to compare: domestic_outgoing, domestic_incoming, international_outgoing_usd, international_outgoing_foreign_currency or international_incoming. | |
| account_type | No | personal (17 banks) or business (9 banks). Default personal. | personal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the marginal bar is low, and the description still adds real behavior: output is ordered ascending by fee, and banks with no published fee or no such service are sorted last with an explanatory reason. That edge-case handling is not derivable from annotations or schema.
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?
Three tight sentences: what it produces, how to scope the call, and how non-qualifying banks are handled. The ranking direction is front-loaded, and no sentence is filler.
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 cover ordering and the 'listed last with reason' case. It leaves unspecified whether fee amounts, effective dates, or source citations come back per bank — a small but real gap for a comparison tool.
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% and both enums are self-describing, so the baseline is 3. The description paraphrases the enum axes in natural language ('in dollars or foreign currency', 'personal or business') and restates the 2–17/omit rule, which is helpful framing but largely repeats structured data.
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 — 'ranks US banks from lowest to highest published fee' — and pins the scope to one wire type across four axes (direction, domestic/international, currency, account type). The multi-bank ranking framing also implicitly separates it from get_bank_wire_fees (single bank) 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?
'Pass 2 to 17 banks, or none to rank every bank covered' gives explicit invocation context, including the omit-to-broaden behavior. It stops short of naming alternatives like find_cheapest_way_to_send_money, so the agent must infer the boundary between ranking fees and computing total send cost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranks money transfer providers by total cost (fee plus exchange-rate margin) for sending $200 or $500 from the US to Mexico, India or the Philippines, from the World Bank Remittance Prices Worldwide survey (Q3 2025), with the corridor average, the ECB reference rate in that currency and providers' published fee rules. Filter by how the recipient gets the money.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many providers to return, cheapest first. Default 10. | |
| country | Yes | Destination: Mexico, India or Philippines (country name, ISO code MX/IN/PH or currency MXN/INR/PHP). | |
| amount_usd | No | Amount sent in US dollars: 200 or 500 (the two amounts the World Bank surveys). Default 200. | |
| receiving_method | No | Optional: only providers paying out to a bank account, cash pickup or mobile wallet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and closed-world, so the description isn't required to cover safety. It does add genuinely useful behavior: the World Bank RPW Q3 2025 source and vintage, that ranking is by total cost including FX margin, and that results carry a corridor average, an ECB reference rate and published fee rules.
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?
Two sentences with no filler. The ranking rule and data source are front-loaded, and the trailing filter sentence covers the one optional control without dragging on.
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 return contract and does it: corridor average, ECB reference rate, fee rules, ordered cheapest-first. It stops short of stating row-level fields or what happens if a corridor/amount pair is unsupported, but an agent has enough to call 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 description coverage is 100% and both enums (amount_usd, receiving_method) are fully documented in the schema. The description adds only the notion that cost = fee + exchange-rate margin, and 'Filter by how the recipient gets the money' restates receiving_method rather than adding 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 opens with a precise verb ('Ranks') and resource ('money transfer providers by total cost'), and states exactly what is compared: fee plus exchange-rate margin. That is clearly distinct from the wire-fee siblings, though no sibling is named for contrast.
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 is implied rather than stated: 'Filter by how the recipient gets the money' hints at the optional receiving_method, and the corridors and $200/$500 amounts scope the query. But it never says when to reach for this instead of compare_bank_wire_fees or get_bank_wire_fees, and doesn't warn that only three corridors are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One US bank's published wire fees: outgoing and incoming domestic wires, international wires sent in dollars or in foreign currency, incoming international wires, same-day cutoff times, fee waivers, what the bank says about its exchange rate, the fee schedule date and the source document link. Personal accounts cover 17 banks and credit unions; business accounts cover 9 banks.
| Name | Required | Description | Default |
|---|---|---|---|
| bank | Yes | Bank name or common short name, e.g. "Chase", "Bank of America", "BofA", "Navy Federal", "Schwab". | |
| account_type | No | personal (consumer checking) or business (business checking). Default personal. | personal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld=false, so the safety profile is covered. The description adds valuable content transparency by enumerating the returned fields, including fee schedule date and source document link, which is the key provenance signal an agent would want.
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?
A single dense sentence, but the core purpose is front-loaded and every listed item is informative rather than filler. Mild length cost from the exhaustive enumeration.
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 return-value burden and does so by listing the fee categories, waivers, exchange-rate commentary, schedule date, and source link. Missing only edge-case behavior (unknown bank, currency of returned fees), which is a modest gap for a read-only lookup.
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 value by quantifying the account_type enum's scope (17 personal institutions vs 9 business). It still doesn't discuss bank-name matching behavior beyond what the schema's examples already say.
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 ('One US bank's published wire fees') and enumerates exactly what is covered: domestic, international, cutoff times, waivers, exchange-rate notes, schedule date, source link. It does not distinguish itself from siblings like get_wire_cutoff_times or compare_bank_wire_fees, which overlap in subject matter, so the agent must infer the single-bank scope from 'One US bank'.
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 phrase 'One US bank's' implies this is the lookup for a known bank, contrasting implicitly with compare_bank_wire_fees, but no explicit when/when-not guidance is given. It also doesn't clarify how this relates to get_wire_cutoff_times despite listing cutoff times as covered content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Same-day wire cutoff times as each bank publishes them (latest first, Eastern time used for sorting), the Fedwire Funds Service operating hours, and the 2026 Federal Reserve holidays. Pass a date to learn whether it is a Fedwire business day and, if not, the next one. Pass a bank to get only its cutoffs.
| Name | Required | Description | Default |
|---|---|---|---|
| bank | No | Optional bank name, e.g. "Wells Fargo". Omit for every bank. | |
| date | No | Optional date in 2026 as YYYY-MM-DD, e.g. 2026-11-27, to check whether Fedwire is open that day. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/non-open-world, so the safety profile is covered. The description adds genuinely non-structured behavior: results are sorted latest-first using Eastern time, and a closed date yields the next business day rather than a bare negative answer. It does not describe output shape or data freshness, so it is not a 5.
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?
Three sentences, front-loaded with what is returned before the parameter instructions. The '(latest first, Eastern time used for sorting)' parenthetical is information-dense and slightly crowded but each clause carries real meaning.
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 two-optional-parameter read-only tool with full schema coverage and rich annotations, the description covers scope, sorting, timezone, and date semantics. The remaining gap is data currency/source freshness and any per-bank coverage caveats, which is minor.
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; the description still adds meaning by explaining the consequence of the date parameter (business-day check plus next open day) and that omitting bank returns all banks. This goes beyond the schema's format examples.
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 names the concrete resources returned: same-day wire cutoff times per bank, Fedwire Funds Service operating hours, and 2026 Federal Reserve holidays. That enumeration clearly separates it from the fee-oriented siblings (get_bank_wire_fees, compare_bank_wire_fees) without ambiguity.
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 invocation guidance: pass a date to check business-day status (and get the next open day), pass a bank to narrow to one institution's cutoffs. It stops short of naming the sibling tools or stating when a different tool (e.g., fee lookup) is the better choice.
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.
compare_bank_wire_feesfind_cheapest_way_to_send_moneyget_bank_wire_feesget_wire_cutoff_timesCheapest way to get paid: every route ranked by fee, from providers' own pricing pages, dated.
Live crypto fees: USDT transfer costs on 12 networks, exchange withdrawals, bridges and gas.
Estimate payments abroad: fees, exchange rates, receiving accounts and payout coverage
Exchange rates, where Morse can send money, and indicative transfer quotes. No login needed.
Add one secure layer between your agents and this server.