IBANforge

Request an IBANforge API key

request_api_key

Request a free IBANforge API key without leaving chat when you hit daily free limits or a 402 error. Works after the limit is reached and requires no email address.

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 hit the daily 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 daily free-tier limit — it works even after the limit is reached.

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.5/5.0

Behavior5/5

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

Annotations contain only a title, so the description carries the full burden. It thoroughly discloses the process: no email required, no leaving the conversation, the key-issuance flow, the need to read `status` first, and the prohibition on opening links or filling forms for the human. It also states that the tool is free and does not count against the daily limit.

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 longer than average but every section earns its place: purpose, usage triggers, result interpretation, required human-facing verbatim display, prohibited actions, and next-step call to poll_api_key. It is structured with labels like 'USE WHEN' and 'WHAT YOU MUST DO WITH THE RESULT,' making it easy for an agent to parse.

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 the tool's interactive key-issuance process and sparse annotations, the description is complete. It tells the agent when to call, how to interpret the result, what to show the human, what not to do, and that poll_api_key should follow. Even though an output schema exists, the description adds essential process context that structured fields could not convey.

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 description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema: both `reason` and `client_name` are already described in the schema as shown to the human on the approval page. No extra parameter guidance is provided.

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 and resource: 'Start the process that gives this session its own free IBANforge API key.' It clearly differentiates from siblings by naming poll_api_key as the next step and by emphasizing the key-requesting role rather than validation or lookup.

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?

The description provides explicit USE WHEN conditions: 'you hit the daily free allowance, a call answers 402, or you are about to run more than a handful of validations.' It also clarifies that the tool works even after the limit is reached. It does not explicitly describe when not to use it or name alternative tools, but the trigger conditions are clear.

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

Deploy Server