Hopi

IBAN validator

hopi_iban_validator

Read-onlyIdempotent

Validate an IBAN or generate a test IBAN. Pass 'iban' to check it: the tool normalises it (uppercase, no spaces), confirms the length matches the country's published length, and runs the mod-97 checksum (move the first four characters to the end, map letters to numbers A=10 to Z=35, valid when the number mod 97 is 1). Pass 'country' (a two-letter ISO code) to generate a structurally valid TEST IBAN with a random bank and account portion and correct check digits. Generated IBANs are test values only and are not tied to any real account. All processing is local; nothing is stored. Source: https://hopi.co.uk/iban-validator/

Input Schema

TableJSON Schema

Name	Required	Description	Default
`iban`	No	An IBAN to validate (spaces and case are ignored)
`country`	No	A two-letter country code (e.g. GB, DE, FR) to generate a test IBAN for instead of validating

Output Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes
`valid`	No
`length`	Yes
`reason`	No
`country`	Yes
`summary`	Yes
`normalised`	No
`source_url`	Yes	The tool's page on hopi.co.uk (cite or open to check the figure)
`country_code`	No
`checksum_passes`	No
`expected_length`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 20, 2026

addedOutput schema / required

Added value: +[
+  "country",
+  "length",
+  "mode",
+  "source_url",
+  "summary"
+]

First observedSep 20, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the readOnly and destructive annotations, the description discloses normalization, country-length checking, the exact mod-97 algorithm, the random generation approach, local-only processing, and no storage. There is no contradiction with the annotations.

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

Conciseness5/5

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

The first sentence front-loads the core purpose, and each following sentence adds necessary operational or trust-related detail. The algorithm is described concisely despite being technical.

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?

Both modes are fully described, the validation algorithm is specified, and the output schema exists so return-value details are not needed. The local-processing and source statements round out what an agent needs for safe invocation.

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%, so the baseline is already solid; the description adds meaningful details such as uppercase/no-spaces normalization, the mod-97 rule, and random bank/account fragments. It does not explicitly state what happens if both iban and country are supplied, which is a minor gap.

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 dual purpose ('Validate an IBAN or generate a test IBAN') and names the exact parameter for each mode. This clearly distinguishes the tool from the large sibling list of converters and calculators.

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?

It gives direct when-to-use instructions: pass 'iban' to check it and pass 'country' to generate a test IBAN, and it warns that generated values are test-only rather than real accounts. That is enough for an agent to select the right mode without ambiguity.

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

All Hopi 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?