Skip to main content
Glama

ibanforge

by io.github.cammac-creator

Send Feedback to IBANforge

send_feedback

Report a problem or a need directly to the IBANforge operators: incorrect validation result, stale or missing BIC/bank data, latency, or anything blocking you from using or PAYING for the service (missing network, unclear pricing, quota shape). USE WHEN: a result looks wrong, data you need is missing, or you hit a wall (quota, payment, capability) and want it fixed. This tool is free and does NOT count against the daily free-tier limit — it works even after the limit is reached. A human reads every report; verified data errors on paid x402 calls are refunded on-chain.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gotNoWhat you received instead (for data errors).
agentNoWhich agent/model is reporting, e.g. "claude-sonnet-5 via MCP".
notesYesWhat happened, what you needed, or what blocked you — free text.
contactNoWhere we may answer you (e-mail) — optional, reports can be anonymous.
endpointNoEndpoint or tool concerned, e.g. /v1/iban/batch.
expectedNoWhat you expected (for data errors).
error_typeYesCategory of the report. Use "other" for product feedback, pricing/payment blockers or feature needs.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesReport id — check status at GET /v1/feedback/{id}.
okYes

TDQS

A4.2/5.0
Behavior4/5

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

Annotations are minimal (only title), so description carries full burden. It discloses that the tool is free, does not consume daily quota, works after limit, a human reads each report, and paid data errors are refunded on-chain. This provides useful behavioral context beyond the title annotation.

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?

Five sentences, front-loaded with purpose, then usage triggers, then behavioral notes. Every sentence adds distinct value, no redundancy. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage guidelines, key behavioral traits, and ties to parameter schema well. Output schema exists so return values are handled. Could mention that reports are anonymous if contact is omitted, but overall complete for a feedback tool.

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% with all 7 parameters described. The description adds context like types of issues but does not enhance individual parameter meanings beyond schema. For example, 'error_type' enum values map to listed scenarios, but no extra guidance on format or examples is provided.

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?

Description clearly states the tool's purpose: 'Report a problem or a need directly to the IBANforge operators.' It lists specific scenarios (incorrect validation, missing data, latency) and distinguishes from sibling tools (validation/lookup) by focusing on feedback and operational issues.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use with 'USE WHEN' clause covering data errors, missing data, or blockers. Mentions it is free and does not count against daily free-tier limit. Does not explicitly mention when not to use or list alternatives, but the context of siblings makes the distinction clear.

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

All ibanforge toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation4/5

Each tool has a distinct job, and the descriptions provide strong USE WHEN/DO NOT USE cues. The only plausible boundary cases are validate_iban vs batch_validate_iban (single vs bulk) and validate_iban vs check_compliance (general enrichment vs payment-risk triage), but both are clearly signposted.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: validate_iban, check_compliance, lookup_bic, send_feedback, etc. batch_validate_iban reads as a compound verb + object and does not break the convention, and the verb choice also aligns with intent: validate for format checks, check for rule/risk checks, lookup for directory data.

Tool Count5/5

Eight tools are well-scoped for an IBAN validation and payment-intelligence API: single/batch validation, compliance, address rules, reference validation, BIC and Swiss clearing lookups, and feedback. Each tool carries a distinct capability and none feels redundant or padding.

Completeness5/5

The surface covers the full IBAN-informed workflow: validation, enrichment, batch processing, BIC/Swiss clearing resolution, payment-reference pairing, postal-address rail rules, and pre-payment compliance triage. Explicit limitations such as not verifying account existence or payee identity are domain constraints, not missing tools.

Resources