IBANforge

Collect the approved IBANforge API key

poll_api_key

Check whether a human approved your API key request and retrieve the key once approved, including how to handle pending, denied, or expired responses.

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 daily free-tier limit.

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?

Annotations contain only a title, so the description carries the full burden of behavioral disclosure. It does this thoroughly: it explains the server may delay up to thirty seconds, the tool must not be called in a tight loop, the key is delivered only once, and each response status implies a specific follow-up action. This is rich, non-obvious behavior that an agent needs to know.

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 organized with clear labels (USE WHEN, HOW TO CALL IT, WHAT THE ANSWERS MEAN). Every sentence carries operational value: rate limiting, status interpretation, retry limits, and fallback behavior. The structure front-loads the core purpose before diving into details, making it easy to scan.

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 polling complexity, output schema presence, and a single optional parameter, the description covers everything an agent needs: when to call, how often, what each response means, how to handle errors, and the free-tier implications. It even specifies the key is delivered once, preventing a critical mistake. No meaningful context 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 the input schema already states that device_code is optional and can be left empty to reuse the last request. The description repeats this guidance but does not add meaning beyond what the schema provides. Baseline 3 is appropriate because the schema handles the parameter documentation.

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 and resource: 'Collect the API key once a human has approved the request opened by request_api_key.' This clearly identifies the tool's role and directly distinguishes it from request_api_key, its primary sibling. The title reinforces the same meaning, and the condition (approved request) is explicit.

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 provides explicit USE WHEN, HOW TO CALL IT, and WHAT THE ANSWERS MEAN sections. It tells the agent exactly when to call poll_api_key, when to wait and retry, when to call request_api_key again, and when to stop entirely. This is far beyond minimal guidance and leaves little to inference.

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

Deploy Server