banking-intelligence

IBAN Validation

iban_validate

Read-only

Validate an IBAN and identify the institution that holds the account.

Performs format check, country-specific length check, and ISO 7064 mod-97 checksum verification. Also returns COUNTRY-level banking rules for the IBAN's country prefix (national currency, SEPA status, expected format).

CROSS-CHECKS THE BENEFICIARY BANK. Where the country's IBAN registry mask defines the bank identifier as four alpha characters (GB, NL, IE, RO, PK, MT, JO, QA, KW and others), bank_identifier.resolved_institution names the institution that actually holds the account, read out of the IBAN itself. Call this whenever the user supplies an IBAN AND names a beneficiary bank or BIC — if the two disagree, that mismatch is a far better explanation for a rejected or returned payment than anything you can infer, and it is invisible without this call. Everywhere else the bank identifier is a NATIONAL bank/sort code (the German BLZ, Italian ABI, French code banque): bank_identifier.code is those characters, is_bic_prefix is false, and no institution is named — quote the code when telling the user what to check, never a bank name derived from it.

A FAILURE IS NOT ALWAYS A CHECKSUM FAILURE. An IBAN of the right length whose characters break the country's mask (a letter where the country requires a digit — O for 0, I for 1) is refused BEFORE mod-97 runs, with format_violations naming the position. Report the position and the character; do not tell the user the check digits are wrong.

valid: true means the check digits are right and NOTHING MORE — not that the account exists, is open, or belongs to the named beneficiary or the named bank. Never rule out the account details on the strength of it when diagnosing a failed payment (see verification_note).

An IBAN encodes country + bank + account number and carries NO currency information. country_currency is the country's national currency, NOT this account's denomination — never infer a currency mismatch or a "resend in X" recommendation from it (see currency_note in the response).

Examples: iban_validate("DE89370400440532013000") iban_validate("GB29 NWBK 6016 1331 9268 19")

Input Schema

TableJSON Schema

Name	Required	Description	Default
`iban`	Yes	The IBAN to check, e.g. "DE89370400440532013000". Spaces and hyphens are ignored and letters are upper-cased.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026

addedInput schema / properties / iban / description

Added value: +"The IBAN to check, e.g. \"DE89370400440532013000\". Spaces and hyphens are ignored and letters are upper-cased."

First observedJun 12, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the semantic burden — and it does: it explains that mask violations are refused before mod-97 and reported via format_violations, and that valid:true means only the check digits pass, not that the account exists or matches the beneficiary. The currency caveat (country_currency is national, not account denomination) is critical behavioral context an annotation cannot convey.

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?

Content is front-loaded (what it does, then the cross-check, then failure modes, then what valid means), but the emphatic all-caps assertions and repeated warnings make it longer than strictly needed for a single-parameter tool. Every paragraph is substantive, yet some points could be tightened.

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?

An output schema exists and the description still names the key response fields an agent must interpret (resolved_institution, bank_identifier.code, is_bic_prefix, format_violations, verification_note, currency_note), so an agent can act on results and avoid the two most likely misreadings.

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 100% and the schema already documents whitespace/hyphen tolerance and upper-casing, so the baseline is 3. The description reinforces this with a spaced GB example that confirms normalization behavior, adding modest value beyond the 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 names a precise verb+resource (validate an IBAN) and states the exact scope: format check, country-length check, mod-97 checksum, plus institution resolution. It distinguishes itself from neighbors like swift_lookup and country_banking_rules by explaining what it returns about the beneficiary bank versus country-level rules.

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 routing: 'Call this whenever the user supplies an IBAN AND names a beneficiary bank or BIC.' It also states the condition under which no institution is named (national bank/sort-code countries) and tells the agent what to quote in that case, and it points to verification_note/currency_note for follow-up.

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

All banking-intelligence 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?