ibanforge

Request an IBANforge API key

request_api_key

Start the process that gives your human a free IBANforge API key, without any e-mail address. The key does not unlock this session: it works once your human puts it in the MCP client configuration and reconnects, or sends it to the REST API, so tell them where it goes when you hand it over: config_line (returned by poll_api_key) for Claude Code with the npm package; for the hosted server https://api.ibanforge.com/mcp, the header "Authorization: Bearer ", which Claude and Claude Desktop take under Request headers when the custom connector is added; ChatGPT sends no key to a connector, so in ChatGPT the key serves on the REST API only. USE WHEN: you used up the free allowance, a call answers 402, or your human is 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "request_api_key"
  }
}

Input 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

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 only cover the safety profile (readOnly=false, idempotent=false, destructive=false), leaving the operational behavior to the description, which delivers richly: the key does not unlock the current session, it requires a human reconnect or REST use, status must be read first, display_to_human must be shown verbatim, the agent must not open the link or invent an e-mail, and the call does not consume the free allowance. These are non-obvious traits an agent would otherwise get wrong.

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?

Purpose and trigger are front-loaded in the first sentence and the 'USE WHEN' / 'WHAT YOU MUST DO' structure is easy to scan. It is nonetheless long, embedding client-specific configuration detail (config_line, Authorization header, ChatGPT caveat) that is useful but dense; slightly more than strictly needed.

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 two-optional-param tool with an output schema, the description covers everything an agent needs: the trigger conditions, the status/display_to_human handling contract, the human hand-off protocol, and the follow-up call. Return-value mechanics are deferred appropriately to the output schema.

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 parameters (reason, client_name) are fully documented there as optional strings shown on the approval page. The description never references them, so it adds no meaning beyond the schema; 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 verb and resource — 'Start the process that gives your human a free IBANforge API key' — and immediately scopes it ('without any e-mail address'), which distinguishes it from poll_api_key, the sibling it explicitly hands off to. An agent can tell what this does and what it does not do (unlock the current session) without opening the schema.

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?

It gives an explicit trigger list: 'USE WHEN: you used up the free allowance, a call answers 402, or your human is about to run more than a handful of validations.' It also names the required follow-up call (poll_api_key) and states the tool is free and works after the allowance is spent, so the agent knows both when to call it and what to do next.

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.