Skip to main content
Glama
Sign In
ibangen-mcp

ibangen-mcp

by offx366
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

generate_test_ibans

Generate synthetic, checksum-valid test IBANs for QA and development, with optional country, bank, quantity, and seed parameters to create repeatable test data.

Instructions

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. Without IBANGEN_API_KEY up to 10 country-level IBANs a day per IP (bank fields hidden); a free key gives 100 API calls a month. bank targets one bank and needs a paid key. Output is test data only and must never be used for payments.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "country": "<country>"
    },
    "name": "generate_test_ibans"
  }
}

Input Schema

NameRequiredDescriptionDefault
bankNo
seedNo
countryYes
quantityNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.5/5.0
Behavior5/5

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 tiered rate limits (10/day per IP unauthenticated vs 100 calls/month with a key), that bank fields are hidden without a key, and that output is synthetic only. These are non-obvious operator constraints an agent cannot infer elsewhere.

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?

Front-loaded purpose sentence, then parameter notes, then limits and a safety warning — logical ordering with little waste. The line-broken layout is slightly fragmented but every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return format needn't be explained, and auth/quota behavior is covered. The only missing piece is the semantics of the `quantity` parameter, minor but relevant to calling 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 coverage is 0%, so the description must compensate; it explains `country` (accepts names like "Germany"/"UK"), `seed` (repeatable output) and `bank` (needs a paid key). `quantity` is left unexplained, which is the one real gap in a 4-parameter tool.

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?

States a specific verb and resource ('Generate synthetic, checksum-valid test IBANs') plus the intended domain (QA and development). This clearly separates it from validate_ibans and generate_us_test_accounts without needing the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for when to use it (QA/dev test data, never for payments) and when a paid key is required for `bank`. It doesn't explicitly name the sibling alternatives (e.g. validate_ibans) or state when not to use it, keeping it just below a 5.

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

Deploy Server

Other Tools