Skip to main content
Glama

HelpMyAgent

by io.github.helpmyagent
OverviewDiscussionsAdmin

IBAN Structure Validation

iban_validate

Validates IBAN structure and mod-97 checksum locally and extracts French bank/branch/account components when present. Use when: Validate an IBAN checksum before using it in a workflow. You need local IBAN normalization, structural validation and mod-97 checksum verification before using an account identifier. For French IBANs, you also want the available bank, branch, account and RIB-key components. Avoid when: You need to verify that an IBAN belongs to a specific supplier; structural validation cannot establish ownership. You need supplier-level public identity/compliance context; use company/fr/supplier-verification. Limitations: A checksum-valid IBAN can still refer to a closed, nonexistent or unrelated bank account. Bank/BIC enrichment is returned only when supported by the endpoint’s available reference data. Price: 0.002 USD per call via x402. Paid-call behavior: source records are not modified, but a successful invocation can consume the advertised x402 payment; the payment-required challenge is free, and repeating the tool after a completed paid invocation may require a new payment. Accepted x402 networks: eip155:8453, xrpl:0.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ibanYesIBAN to normalize and validate structurally, including the ISO 13616 mod-97 checksum. (minimum length 15; maximum length 34).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
bicYesStructured value returned for “bic” as defined by this API contract.
ibanYesStructured value returned for “iban” as defined by this API contract.
validYesWhether the supplied identifier passed the endpoint’s validation rules.
rib_keyYesStructured value returned for “rib key” as defined by this API contract.
bank_codeYesStructured value returned for “bank code” as defined by this API contract.
bank_nameYesStructured value returned for “bank name” as defined by this API contract.
checked_atYesUTC timestamp at which HelpMyAgent performed the check.
branch_codeYesStructured value returned for “branch code” as defined by this API contract.
limitationsNoKnown interpretation, source-coverage or freshness limitations for this result.
country_codeYesStructured value returned for “country code” as defined by this API contract.
account_numberYesStructured value returned for “account number” as defined by this API contract.
checksum_validYesStructured value returned for “checksum valid” as defined by this API contract.
expected_lengthYesStructured value returned for “expected length” as defined by this API contract.
structure_validYesStructured value returned for “structure valid” as defined by this API contract.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / required
      Previous value: -[
-  "iban",
-  "country_code",
-  "structure_valid",
-  "checksum_valid",
-  "valid",
-  "expected_length",
-  "bank_code",
-  "branch_code",
-  "account_number",
-  "rib_key",
-  "bic",
-  "bank_name",
-  "checked_at",
-  "limitations"
-]New value: +[
+  "iban",
+  "country_code",
+  "structure_valid",
+  "checksum_valid",
+  "valid",
+  "expected_length",
+  "bank_code",
+  "branch_code",
+  "account_number",
+  "rib_key",
+  "bic",
+  "bank_name",
+  "checked_at"
+]
  2. Changed17 schema fields changed
    • addedInput schema / description
      Added value: +"Structured input parameters for the iban/validate API."
    • addedInput schema / properties / iban / description
      Added value: +"IBAN to normalize and validate structurally, including the ISO 13616 mod-97 checksum. (minimum length 15; maximum length 34)."
    • addedOutput schema / description
      Added value: +"Structured result returned by the iban/validate API."
    • addedOutput schema / properties / account_number / description
      Added value: +"Structured value returned for “account number” as defined by this API contract."
    • addedOutput schema / properties / bank_code / description
      Added value: +"Structured value returned for “bank code” as defined by this API contract."
    • addedOutput schema / properties / bank_name / description
      Added value: +"Structured value returned for “bank name” as defined by this API contract."
    • addedOutput schema / properties / bic / description
      Added value: +"Structured value returned for “bic” as defined by this API contract."
    • addedOutput schema / properties / branch_code / description
      Added value: +"Structured value returned for “branch code” as defined by this API contract."
    • addedOutput schema / properties / checked_at / description
      Added value: +"UTC timestamp at which HelpMyAgent performed the check."
    • addedOutput schema / properties / checksum_valid / description
      Added value: +"Structured value returned for “checksum valid” as defined by this API contract."
    • addedOutput schema / properties / country_code / description
      Added value: +"Structured value returned for “country code” as defined by this API contract."
    • addedOutput schema / properties / expected_length / description
      Added value: +"Structured value returned for “expected length” as defined by this API contract."
    • addedOutput schema / properties / iban / description
      Added value: +"Structured value returned for “iban” as defined by this API contract."
    • addedOutput schema / properties / limitations / description
      Added value: +"Known interpretation, source-coverage or freshness limitations for this result."
    • addedOutput schema / properties / rib_key / description
      Added value: +"Structured value returned for “rib key” as defined by this API contract."
    • addedOutput schema / properties / structure_valid / description
      Added value: +"Structured value returned for “structure valid” as defined by this API contract."
    • addedOutput schema / properties / valid / description
      Added value: +"Whether the supplied identifier passed the endpoint’s validation rules."
  3. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations are sparse (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description carries the burden. It discloses paid-call behavior, x402 payment consumption, that source records are not modified, and that enrichment is conditional on reference data. It does not contradict annotations. It could add more about output shape, but the output schema exists and the description covers the key behavioral traits.

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 well-structured with clear 'Use when', 'Avoid when', 'Limitations', and 'Price' sections. It is slightly long but every section earns its place by providing actionable guidance. The most important information (what it validates) is front-loaded.

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?

Given the tool's moderate complexity (one parameter, output schema present, paid-call behavior), the description covers the essential context: what it validates, when to use it, when not to, limitations, and payment implications. It doesn't detail the output structure, but the output schema exists and the description is otherwise complete for an agent to select and invoke the tool 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 100% and the single parameter 'iban' is well-described in the schema. The description adds context about normalization, structural validation, mod-97 checksum, and French component extraction, which enriches the meaning of the parameter beyond the schema's basic type/length constraints.

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 states a specific verb ('Validates'), a clear resource ('IBAN structure and mod-97 checksum'), and a distinctive extra ('extracts French bank/branch/account components when present'). It clearly distinguishes itself from sibling tools like vat_eu_validate and company_fr_supplier_verification by naming what it does and does not do.

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 explicitly says 'Use when' and 'Avoid when', giving concrete conditions and naming the alternative (company/fr/supplier-verification) for ownership checks. It also states limitations about checksum-valid IBANs not proving account existence, which is essential guidance for correct tool selection.

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

All HelpMyAgent toolsInspect
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