Skip to main content
Glama
cammac-creator

IBANforge

by cammac-creator
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Batch Validate IBANs

batch_validate_iban
Read-onlyIdempotent

Validate up to 100 IBANs at once to clean spreadsheets, dedupe customer databases, or triage payout lists. Returns valid count and cost in USDC.

Instructions

Validate up to 100 IBANs in a single call. Paid per call in USDC via x402, an IBAN costs $0.002 here instead of $0.005 for validate_iban; on a key or prepaid credits, each IBAN uses one request or one credit either way. USE WHEN: the user pastes a list of IBANs, asks to clean a CSV/spreadsheet of bank accounts, asks to dedupe a customer database, asks to triage a payout list before sending, or whenever you would otherwise call validate_iban more than 2-3 times in a row. RETURNS: { results: [...same shape as validate_iban], count, valid_count, cost_usdc }. COST: via x402, 0.002 USDC per IBAN (e.g. 10 IBANs = 0.02, 100 IBANs = 0.20); on a key or prepaid credits, one request or one credit per IBAN.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ibansYesArray of IBAN strings (1 to 100 entries).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesNumber of IBANs processed.
resultsYesOne entry per input IBAN, in the same order. Same shape as validate_iban output.
cost_usdcNoActual USDC charged for this call.
valid_countYesHow many were valid.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.8.0
    • addedOutput schema / properties / results / items / properties / bic / description
      Added value: +"null when the bank code resolves no BIC."
    • changedOutput schema / properties / results / items / properties / bic / type
      Previous value: -"object"New value: +[
+  "object",
+  "null"
+]
  2. Changed4 schema fields changedv1.4.4
    • addedOutput schema / properties / count
      Added value: +{
+  "description": "Number of IBANs processed.",
+  "type": "number"
+}
    • removedOutput schema / properties / summary
      Removed value: -{
-  "properties": {
-    "invalid": {
-      "type": "number"
-    },
-    "total": {
-      "type": "number"
-    },
-    "valid": {
-      "type": "number"
-    }
-  },
-  "type": "object"
-}
    • addedOutput schema / properties / valid_count
      Added value: +{
+  "description": "How many were valid.",
+  "type": "number"
+}
    • changedOutput schema / required
      Previous value: -[
-  "results",
-  "summary"
-]New value: +[
+  "results",
+  "count",
+  "valid_count"
+]
  3. Addedv1.2.2
  4. Removedv1.2.1
  5. Addedv1.2.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds crucial behavioral context beyond that: the 100-IBAN limit, the cost structure (USDC per IBAN, or credits/requests), and the exact return shape (results, count, valid_count, cost_usdc). No contradiction with 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 well-structured with clear sections (first sentence, USE WHEN, RETURNS, COST). It front-loads the core action and then provides decision-relevant details. Every sentence adds value—no fluff or redundancy—making it appropriately concise for a complex batch tool.

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 tool with a single array parameter, an output schema, and cost implications, the description is complete. It covers when to use it, what it returns, the cost model, and the limit. The agent has everything needed to invoke it correctly without additional lookups. The output schema is not shown but the return shape is explicitly described.

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?

The input schema covers the only parameter (ibans) with a clear description and constraints (1-100 items). The tool description does not add additional parameter-level meaning beyond restating the array and limit; it focuses on usage and cost. Since schema coverage is 100%, 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 and resource: 'Validate up to 100 IBANs in a single call.' It clearly distinguishes itself from the sibling validate_iban by emphasizing the batch nature and the explicit contrast in cost and usage. The purpose is unambiguous and immediately actionable.

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' scenarios (pasted lists, cleaning CSVs, deduping databases, triaging payout lists) and directly names the alternative (validate_iban) with a threshold ('more than 2-3 times in a row'). This gives the agent precise decision rules for tool selection.

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

Deploy Server

Other Tools