IBANforge

Collect the approved IBANforge API key

poll_api_key

Check whether a human approved your API key request, retrieving the key once approved and handling pending, denied, or expired outcomes.

Instructions

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`	No	anonymous = the entry allowance, email/claimed/paid = the raised one.
`email`	No	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`	No	Present exactly once, on the first approved poll.
`message`	Yes	One sentence for the human.
`expires_in`	No
`key_prefix`	No
`config_line`	No	The exact command line to give the human. Do not run it yourself.
`monthly_limit`	No
`retry_in_seconds`	No

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?

The description is exceptionally transparent about polling behavior, retry semantics, and the one-time nature of the approved key. It also explains every possible response state and the correct agent action for each. Because annotations carry no behavioral hints, this description fully compensates.

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 highly structured with clear labeled sections: USE WHEN, HOW TO CALL IT, and WHAT THE ANSWERS MEAN. Every sentence conveys essential operational information with almost no filler.

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 polling tool with multiple response states and retry rules, the description covers all necessary scenarios: pending, approved, denied, expired, and invalid grant. It also clarifies the cost/allowance behavior, leaving no ambiguity about how to handle this tool correctly.

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 coverage is 100% for the single optional parameter, and the description repeats the schema's guidance about leaving device_code empty to reuse the last request. It adds helpful calling cadence context but not new parameter-level semantics, so the baseline of 3 is appropriate.

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 opens with a specific verb+resource pair ('Collect the API key') and grounds it in the prior step ('request opened by request_api_key'). It clearly identifies the tool's distinct role among siblings like 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?

The 'USE WHEN' section states the exact precondition: call request_api_key and show the code to the human. It also gives concrete polling guidance ('once per minute is enough, never in a tight loop'), which tells the agent how to behave in practice.

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

Deploy Server