Skip to main content
Glama

Validate IBAN or BIC

validate_identifier
Read-onlyIdempotent

Validate an IBAN or BIC identifier in one call. Returns pass/fail and an error explanation when invalid.

Instructions

Validate a single financial identifier (IBAN or BIC).

Use this for a one-off identifier check with a clear pass/fail and
reason. To validate identifiers embedded across a whole batch, prefer
``validate_records`` / ``validate_payment_scheme`` instead of calling
this per field.

Returns ``{"kind": str, "value": str, "valid": bool, "error": str}``
(the ``error`` key is present only when ``valid`` is ``False``).

Args:
    kind: One of ``"iban"`` or ``"bic"`` (case-insensitive).
    value: The identifier value to check.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYesWhich identifier to validate: 'iban' or 'bic' (case-insensitive). Any other value returns an error.
valueYesThe identifier string to check — an IBAN or BIC/SWIFT code matching the chosen kind.
Behavior4/5

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

Annotations already show readOnly=true and idempotent=true. The description adds the return format (kind, value, valid, error) and explains the conditional presence of error key, providing useful behavioral context beyond what annotations offer.

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?

Two well-structured paragraphs, front-loaded with purpose, no unnecessary words. Usage guideline is presented before return format, aiding quick comprehension.

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?

For a simple validation tool with comprehensive schema and annotations, the description fully covers what the agent needs: purpose, when to use, return format, and parameter details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for both parameters. The description adds marginal value by noting case-insensitivity for kind and the error behavior, but doesn't significantly extend beyond 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 clearly states the verb 'validate' and the resource 'single financial identifier (IBAN or BIC)', and distinguishes it from sibling tools like validate_records and validate_payment_scheme by emphasizing it's for one-off checks.

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?

Explicitly states when to use (one-off identifier check) and when not (batches), naming alternatives validate_records and validate_payment_scheme.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sebastienrousseau/pain001-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server