Skip to main content
Glama

swift_lookup

Search banks and financial institutions by name, SWIFT/BIC code, or country.

Covers both SWIFT-connected banks and non-SWIFT financial institutions (e-money issuers, payment processors, MFOs, brokerages, VASPs, etc.).

Returns: SWIFT/BIC code (if any), name, city, country, institution type, GPI membership, a coarse sanctions FLAG across 7 hard-sanctions watchlists (OFAC SDN, EU, UK, CA, CH, AU, NZ — see sanctions_note; this is NOT a full screen, use sanctions_screen for a compliance verdict), and enriched bank profile when available.

EVERY BANK COMES BACK SAYING WHETHER WE HOLD ITS CORRESPONDENT CHAIN. Read settlement_instructions on each bank: on_file: true with a currencies_on_file count means we hold that BIC8's actual correspondent BIC, nostro account number and national clearing ID, and read_with is the exact ssi_lookup call that returns them. on_file: false means we hold none in any currency — a gap in our data, not a finding about the bank. A null is "not established yet" and is neither. This is the answer to "which intermediary bank do I put on the instruction?", and it is a fact we either have or do not have — never one to recall from training data.

The country parameter accepts both 2-letter ISO codes ("ID", "DE") and full English names ("Indonesia", "Germany"). Names are resolved automatically.

A BIC IDENTIFIES AN OFFICE, NOT A BRAND, AND THE DIFFERENCE IS PRICED. A name search returns ONE representative office per bank, elected by BIC convention rather than by relevance to the payment, and office_note says so whenever the bank holds more than one. Published tariffs, correspondent chains and settlement instructions are filed per BIC, so the choice changes the answer: transfer_cost("COBADEFF") returns Commerzbank's published 0.15% sending fee and transfer_cost("COBADEBB") refuses for want of a filed tariff, and both of those are Commerzbank AG in Germany. So:

  • If the user named a CITY, put it in the query — "Commerzbank Frankfurt" resolves to the Frankfurt office, and the plain name cannot.

  • If they did not, ask which BIC is on their statement or payment instruction before pricing or routing, and say which office you used.

  • Never present a representative office's BIC as "the bank's BIC".

Examples: swift_lookup("DEUTDEFF") # exact BIC lookup swift_lookup("Deutsche Bank") # search by name swift_lookup("Commerzbank Frankfurt") # bank + city -> that office's BIC swift_lookup("TBC PAY") # find non-SWIFT payment processor swift_lookup("bank", country="KZ") # explore banks in a country swift_lookup("Halyk", country="KZ") # find specific bank in country swift_lookup("Bank Mandiri", country="Indonesia") # full country name OK

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
countryNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It does very well: it explains that on_file:true/false/null are three distinct states (holding correspondent data, a data gap, or not yet established), that representative-office selection can change results, that a BIC identifies an office not a brand, and that the sanctions flag is coarse and not a compliance verdict. These are non-obvious behavioral traits that an agent must know before relying on results.

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

Conciseness4/5

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

The description is long, but every block carries load-bearing information: settlement_instructions semantics, the office-vs-brand rule, the sanctions caveat, country-format handling, and examples. It is front-loaded with the core search purpose and then builds outward; the only minor efficiency cost is that the same offices/ BIC nuance could be tightened slightly, but the length is justified by the high consequences of miscalling this tool.

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 domain complexity, the presence of an output schema, and the high stakes of misinterpretation, the description is complete. It covers the tool's scope, return nature, important policy (`on_file`) states, correct alternatives (`ssi_lookup`/`sanctions_screen`), input formats, and a set of examples covering BIC, name, city, country, and non-SWIFT institutions. There is no obvious missing detail an agent would need to invoke it correctly.

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 0%, so the description must compensate for the parameters. It thoroughly explains query semantics (can be BIC, name, bank+city, or country-specific) and country semantics (2-letter ISO or full English name, auto-resolved). It does not describe the limit parameter, but the integer default of 20 in the schema makes its meaning inferable, so the omission is minor. Overall, the description adds substantial meaning that is not visible in the bare schema.

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 opens with a specific verb-resource pair: "Search banks and financial institutions by name, SWIFT/BIC code, or country." It goes further and distinguishes its coverage from purely SWIFT-connected banks by including non-SWIFT entities, and it explicitly differentiates its output from sanctions_screen and ssi_lookup, so an agent can immediately recognize this as a bank/financial-institution lookup rather than a compliance or settlement-data tool.

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?

The description gives explicit when-to-use guidance and names alternatives: it says the settlement_instructions field points to the exact ssi_lookup call to retrieve correspondent details, and that the sanctions flag is NOT a full screen and to use sanctions_screen for a compliance verdict. It also provides concrete operator guidance on city disambiguation and BIC office selection, which is directly actionable.

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