Skip to main content
Glama

ibanforge

by io.github.cammac-creator

Check Swiss QR-bill Payload

check_swiss_qr_bill
Read-onlyIdempotent

Check a Swiss QR-bill payload, the text a QR-bill's code carries (starts with SPC), rule by rule, each finding citing the SIX document it comes from. USE WHEN: an agent, an ERP or an accounting tool holds a scanned or generated QR-bill and must know before paying or issuing it whether it is well-formed, whether the reference type matches the IBAN (QRR needs a QR-IBAN, IID 30000-31999), and above all whether the creditor and debtor addresses are STRUCTURED (type S) or still COMBINED (type K): the standard removed type K on 21.11.2025 and banks stop processing payments built on it from 14.11.2026. DO NOT USE to learn which bank holds the account or its payment-rail participation: that is the paid validate_iban. RETURNS: { valid, ready_for_2026_11_14, creditor_iban { value, valid, country, qr_iban, iid }, creditor { present, address, structured, sps_check, proposed_structured }, ultimate_debtor, amount, currency, reference { type, value, valid, note }, findings [{ code, severity, field, detail, source }], next_steps, source }. A combined address comes back with proposed_structured, the S-type fields derived from the combined lines, to relay as a fix. IMPORTANT: relay each finding's source string. COST: $0 per call, on every surface (free: 10 units/IP/day on this transport, one per call and one per IBAN in batch_validate_iban, or a free API key at POST https://api.ibanforge.com/v1/keys/generate for 200 REST calls/month).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
payloadYesThe Swiss QR Code text with real line breaks: SPC, 0200, 1, IBAN, creditor (7 lines), ultimate creditor (7 empty lines), amount, currency, ultimate debtor (7 lines), reference type, reference, message, EPD, optional billing information and alternative schemes.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
validYesTrue when no finding has severity error.
amountYes
codingYes
sourceYes
qr_typeYes
trailerYes
versionYes
creditorYes
currencyYes
findingsYes
referenceYes
next_stepsYes
creditor_ibanYes
ultimate_debtorYes
alternative_schemesYes
billing_informationYes
ready_for_2026_11_14Yesvalid AND every present address is structured (type S): what banks require from 14.11.2026.
unstructured_messageYes
ultimate_creditor_emptyYes

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive; the description goes further by disclosing rule-by-rule checking, citation of the SIX source per finding, special handling for combined addresses (proposed_structured), the full return contract, and cost/rate-limit behavior. No annotation contradiction.

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 every portion earns its place and is scannable through explicit labels (USE WHEN, DO NOT USE, RETURNS, IMPORTANT, COST). Core purpose is front-loaded in the first sentence.

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 regulation-heavy validation tool, it covers use case, exclusions, deadline, return schema, required source relay, and cost. An agent has enough context to call it correctly and to route non-matching needs to validate_iban.

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 already documents the payload structure to 100% (SPC line by line), so the baseline is 3. The description adds only the semantic framing that the payload is the text a QR-bill's code carries and starts with SPC, without adding new parameter format or edge-case details.

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 opening sentence names a specific verb ('Check'), a concrete resource ('a Swiss QR-bill payload'), and a distinguishing trait: it processes the SPC text rule by rule, citing SIX documents. This separates it from siblings such as validate_iban and validate_payment_reference without needing to open their schemas.

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?

It gives explicit USE WHEN conditions (scanned/generated QR-bill before paying or issuing, reference-IBAN matching, S vs K address forms) and an explicit DO NOT USE with the alternative (paid validate_iban). It also names the exact deadline context that should drive an agent to this tool.

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