IBANforge

Request an IBANforge API key

request_api_key

Get a free IBANforge API key without an email address when your validation quota runs out or you need more checks; approve the link to receive a code, then poll for it.

Instructions

Start the process that gives this session its own free IBANforge API key, without any e-mail address and without leaving your conversation. USE WHEN: you used up the free allowance, a call answers 402, or you are about to run more than a handful of validations. WHAT YOU MUST DO WITH THE RESULT: read status first — ok means a code was issued, anything else means no code exists and display_to_human tells you and your human what to do instead. On ok, show display_to_human to your human VERBATIM (the user_code and the link) and say, in your own words, that opening the link and approving takes about fifteen seconds and asks for nothing. Do NOT open the link yourself, do NOT fill anything in on their behalf, and do NOT invent an e-mail address: the page gives a key with no address at all, and your human may add one if THEY choose. Then call poll_api_key. This tool is free and does NOT count against the free allowance — it works even after the allowance is spent.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`reason`	No	Optional. What the key is for, shown to the human on the approval page.
`client_name`	No	Optional. Who is asking, shown to the human on the approval page.

Output Schema

TableJSON Schema

Name	Required	Description
`status`	Yes	ok means a code was issued. Anything else: read display_to_human and fall back.
`interval`	No	Minimum seconds between two poll_api_key calls.
`user_code`	No	Show this to the human, exactly as written, e.g. WDJB-MJHT.
`expires_in`	No	Seconds until the code stops working.
`display_to_human`	Yes	A ready-made block of text to show verbatim. Do not paraphrase it.
`verification_uri`	No	The page the human opens. Never open it yourself.
`verification_uri_complete`	No	Same page with the code pre-filled. This is the one to show.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.7.0Sep 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With only a title annotation, the description carries full behavioral burden and meets it: it reveals that the tool starts a multi-step approval flow, that results must be read via `status`, that it is free and does not count against the allowance, and that the agent must not open links or fill forms. This goes well beyond a simple 'request an API key' statement.

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 description is long but tightly structured with USE WHEN and WHAT YOU MUST DO sections, all critical instructions are front-loaded, and every sentence carries actionable information. No filler or repetition that detracts.

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?

Given two optional parameters and a rich output, the description fully covers the decision to call, the post-call handling, the verbatim display requirement, and the prohibition on agent actions. It also clarifies that the tool works even after the allowance is exhausted, leaving no ambiguity.

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?

Both parameters (reason, client_name) are optional and already have descriptions in the schema, so the 100% schema coverage carries the meaning. The tool description adds context that these appear on the approval page but does not add new semantic content beyond the 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?

States a specific verb+resource: 'Start the process that gives this session its own free IBANforge API key'. This clearly distinguishes it from sibling tools like validate_iban or poll_api_key, and names the follow-up tool explicitly.

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?

Includes an explicit 'USE WHEN' section with concrete triggers: 'you used up the free allowance, a call answers 402, or you are about to run more than a handful of validations.' It also names the alternative/follow-up poll_api_key and gives negative instructions, so an agent knows exactly when to call it.

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

Deploy Server