ibanforge

Request an IBANforge API key

request_api_key

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`	Yes	Minimum seconds between two poll_api_key calls.
`user_code`	Yes	Show this to the human, exactly as written, e.g. WDJB-MJHT.
`expires_in`	Yes	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`	Yes	The page the human opens. Never open it yourself.
`verification_uri_complete`	Yes	Same page with the code pre-filled. This is the one to show.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations say readOnlyHint=false, which the description matches by describing an active process. It adds crucial behavioral details beyond annotations: no email needed, the human approval link flow, the need to read 'status' first, the prohibition on opening the link or filling forms on the human's behalf, and that it does not count against the free allowance.

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 long but well-structured with clear sections (USE WHEN, RESULT handling, prohibitions) and front-loads the core purpose. Every sentence carries necessary operational instruction; the prohibitions are repetitive but each addresses a distinct risk.

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?

The description covers the entire lifecycle: when to call, how to interpret the result, what to display to the human, what actions to avoid, and the next tool to invoke. Despite the tool's asynchronous human-approval complexity, nothing an agent needs is missing.

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% and both optional parameters already have clear descriptions, including that they appear on the approval page. The tool description adds no extra meaning beyond referencing the approval page display, which the schema already covers. Baseline 3 applies.

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 action ('Start the process that gives this session its own free IBANforge API key') with a clear resource and outcome. It differentiates from sibling poll_api_key by positioning itself as the initiating step and explicitly directing to call poll_api_key afterward.

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 gives explicit 'USE WHEN' conditions: used up the free allowance, a call answers 402, or about to run more than a handful of validations. It also clarifies the tool works even after the allowance is spent, leaving no ambiguity about when to invoke it.

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

All ibanforge 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.