Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ibangen-mcp is DE89370400440532013000 a valid IBAN?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Official MCP server for IBANgen, the IBAN generator and validator for payment testing.
MCP server that gives AI agents three IBANgen tools:
Tool | Key needed | What it does |
| No (10 IBANs per call, small daily allowance per IP) | Country format, length and MOD-97 checksum. Paid keys add bank, BIC and SEPA Instant / VoP reachability. |
| Yes | Synthetic, checksum-valid test IBANs; optional |
| Yes (bank-intelligence plan) | BIC or domestic identifier to registry records with sources. |
Generated IBANs are test data only. A valid IBAN does not prove that an account exists.
pip install ibangen-mcpRelated MCP server: mcp-europe-business
{
"mcpServers": {
"ibangen": {
"command": "ibangen-mcp",
"env": { "IBANGEN_API_KEY": "your_key_optional_for_validation" }
}
}
}Cursor uses the same block in .cursor/mcp.json. Get a key at https://ibangen.com/apidoc#auth.
IBANGEN_API_BASE_URL overrides the default https://ibangen.com/api/v1.
Generate synthetic, checksum-valid test IBANs for QA and development.
country is a country name such as "Germany" or "UK". seed makes the output
repeatable. bank targets one bank (paid plans). Requires IBANGEN_API_KEY.
Output is test data only and must never be used for payments.
| Name | Required | Description | Default |
|---|---|---|---|
| bank | No | ||
| seed | No | ||
| country | Yes | ||
| quantity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the IBANGEN_API_KEY auth requirement, the paid-plan gating on the bank parameter, seed-based determinism, and the safety-critical constraint that output is test-only. It does not describe rate limits, error behavior, or failure modes when a country/bank combination is unsupported.
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?
Four short sentences with zero filler, opening on the core purpose and then walking parameters and the safety caveat in priority order. Every sentence adds 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?
An output schema exists so return values need not be explained, and the description covers purpose, auth, plan gating, and the safety constraint. The only real gap is the undocumented quantity parameter and unstated behavior for invalid country/bank inputs.
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 0%, so the description must compensate, and it explains three of four parameters: country format ('Germany' or 'UK'), the repeatability semantics of seed, and the plan restriction on bank. The quantity parameter is never mentioned, leaving one undocumented at 0% coverage.
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 precise verb and resource ('Generate synthetic, checksum-valid test IBANs') and scopes it to QA/development. This is unmistakably distinct from the siblings lookup_bank and validate_ibans, so an agent can route 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?
Clearly frames the context ('for QA and development') and adds a hard exclusion ('must never be used for payments'), which is genuinely useful routing guidance. It does not explicitly name when to prefer a sibling (e.g., use validate_ibans to check real IBANs), so it stops short of full alternative coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a BIC or domestic bank identifier to registry records with sources.
Requires IBANGEN_API_KEY on a plan that includes bank intelligence.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| identifier_type | No | bic |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses an auth/plan requirement and that results carry sources, but says nothing about rate limits, error behavior when the identifier is unknown, or whether the lookup is read-only (implied but unstated). Partial coverage for a tool with zero annotation support.
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 tight sentences with the core purpose front-loaded and the prerequisite second. Slightly under-specified rather than verbose, and the stray blank line adds no cost but no value either.
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-parameter read lookup with no output schema and no annotations, the description covers the purpose and the API-key prerequisite adequately, but leaves the parameter contract and error/lookup-miss semantics unaddressed. Adequate at best, with visible 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 0% for both parameters, so the schema offers no help. The description partially compensates by revealing that the input can be a BIC or a domestic bank identifier, which hints at what the opaque 'value' and default 'bic' identifier_type accept, but it never names the parameter or enumerates the allowed identifier types.
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 gives a specific verb and resource: 'Resolve a BIC or domestic bank identifier to registry records with sources.' That is materially more informative than the bare name and clearly differs in domain from the sibling tools (validate_ibans, generate_test_ibans), though it never names or contrasts them explicitly.
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 states a precondition (IBANGEN_API_KEY on a plan with bank intelligence) but gives no guidance on when to reach for this tool versus validate_ibans or generate_test_ibans. A precondition is not usage guidance; the agent is left to infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate IBANs: country format, length and MOD-97 checksum.
Works without an API key for up to 10 IBANs per call (small daily allowance per IP). With IBANGEN_API_KEY set, paid plans also return the bank, BIC and SEPA Instant / Verification of Payee reachability. A valid result does not prove that an account exists.
| Name | Required | Description | Default |
|---|---|---|---|
| ibans | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses auth requirements (key optional), rate limits (10 per call, daily per-IP allowance), the difference in returned data between free and paid tiers, and the critical caveat that a valid result does not prove an account exists.
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?
Four tight sentences, front-loaded with the core purpose, then limits, then tier differences, then the honest caveat. Every sentence adds distinct information with no redundancy.
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?
Output schema exists, so return structure need not be restated; the description still usefully previews what paid plans return. Tiering, limits, and the account-existence caveat cover everything an agent needs to invoke and interpret this 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?
One parameter (ibans array) with 0% schema coverage, so the schema adds nothing. The description implies batching of multiple IBAN strings and adds a meaningful constraint (max 10 per call), but does not describe the expected string format per element.
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 (Validate) and resource (IBANs) and enumerates exactly what is checked: country format, length, MOD-97 checksum. This cleanly separates it from the sibling generate_test_ibans (creates rather than checks) without needing to name it.
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 clear operating conditions: works without an API key up to 10 IBANs per call, and setting IBANGEN_API_KEY unlocks bank/BIC/reachability data. It does not explicitly say when to prefer this over lookup_bank, so it stops short of full alternative routing.
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.
v0.1.1generate_test_ibanslookup_bankvalidate_ibansScored across 3 tools
Each tool has a distinct primary purpose: registry lookup by BIC/identifier, IBAN validation, and synthetic test data generation. The only minor overlap is that validate_ibans also returns bank/BIC data on paid plans, which slightly blurs the line with lookup_bank, but the core intents are clearly separable.
All three tools follow a clean verb_noun snake_case pattern: lookup_bank, validate_ibans, generate_test_ibans. The convention is uniform and self-explanatory with no mixed styles.
Three tools is on the lean side but reasonable for a focused IBAN/bank-intelligence utility. Each tool earns its place (validate, lookup, generate), though the surface is thin enough that it borders on minimal.
Core workflows—validating IBANs, resolving bank records, and generating test data—are covered, giving a coherent lifecycle for the domain. Minor gaps exist, such as IBAN parsing/component extraction or standalone BIC validation, but agents can work around these.
IBAN validation, extraction, format specs and BIC/SWIFT lookup tools for AI assistants.
Cross-border payment & banking intelligence for AI agents: SWIFT/BIC, IBAN, sanctions, FX, tracking.
Utility data for AI agents: IBAN, EU holidays, VAT rates, time zones, ECB FX. Pay per call.
Validate IBANs in 111 countries; bank directory checks for DE, AT, BE, FR, LU, NL, PT and ES.
