ibanforge

Collect the approved IBANforge API key

poll_api_key

Collect the API key once a human has approved the request opened by request_api_key. USE WHEN: you have called request_api_key and shown the code to your human. HOW TO CALL IT: leave device_code empty to reuse the last request from this session. The server usually waits up to thirty seconds before answering, and sometimes answers at once when it is busy — either way, calling it once per minute is enough, never in a tight loop. WHAT THE ANSWERS MEAN: authorization_pending is normal and means nobody has approved yet — wait retry_in_seconds and call again; approved carries the key ONCE and never again, so hand it to your human immediately together with config_line; access_denied means somebody refused — tell your human, ask THEM whether to try again, and open at most ONE more request; expired_token means the code timed out — you may call request_api_key ONE more time, and if that expires too, stop and keep using the keyless allowance or x402; invalid_grant means this code can no longer be used at all — stop. This tool is free and does NOT count against the free allowance.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`device_code`	No	Optional. Leave it empty to reuse the last request from this session.

Output Schema

TableJSON Schema

Name	Required	Description
`tier`	Yes	anonymous = the entry allowance, email/claimed/paid = the raised one.
`email`	Yes	Absent on the anonymous tier: no address was ever given.
`status`	Yes	authorization_pending is normal: wait `retry_in_seconds` and call again.
`api_key`	Yes	Present exactly once, on the first approved poll.
`message`	Yes	One sentence for the human.
`expires_in`	Yes
`key_prefix`	Yes
`config_line`	Yes	The exact command line to give the human. Do not run it yourself.
`monthly_limit`	Yes
`retry_in_seconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 15, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The annotations only say the operation is not read-only, not idempotent, and not destructive. The description goes far beyond this by explaining one-time key delivery, normal waiting behavior, polling cadence, and what each response code means in terms of state and required human interaction. There is no contradiction with the annotations.

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 dense but every section earns its place: USE WHEN, HOW TO CALL IT, and WHAT THE ANSWERS MEAN. It is front-loaded with the core purpose, then branches into actionable decision logic without redundancy.

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 stateful polling tool with subtle one-time delivery semantics, the description fully covers all response cases, retry timing, failure handling, human involvement, and fallback options. The output schema may exist, but the description still supplies the behavioral context needed to act correctly on each outcome.

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

Parameters4/5

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

The schema already documents the single optional device_code parameter at 100% coverage, so the schema carries the definition. The description reinforces that leaving it empty reuses the last request and adds practical calling guidance that is not in the schema, such as not tight-looping.

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 ('Collect') and resource ('API key'), and ties it directly to the prior request_api_key flow. This clearly distinguishes the tool from its siblings, especially request_api_key.

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?

Provides explicit USE WHEN conditions, tells the agent how to call it, how often to poll, when to stop, and when to fall back to alternatives like x402 or the keyless allowance. It even enumerates the exact next action for each possible response, leaving no ambiguity.

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.