Skip to main content
Glama

Check Swiss QR-bill Payload

check_swiss_qr_bill
Read-onlyIdempotent

Validate a Swiss QR-bill payload rule by rule, citing SIX sources, to confirm it is well-formed, matches reference type to IBAN, and flags combined addresses before the 2026 cutoff.

Instructions

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: free (routed to POST /v1/ch/qr-bill/check).

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.
amountNo
codingNo
sourceYes
qr_typeNo
trailerNo
versionNo
creditorNo
currencyNo
findingsYes
referenceNo
next_stepsYes
creditor_ibanNo
ultimate_debtorNo
alternative_schemesNo
billing_informationNo
ready_for_2026_11_14Yesvalid AND every present address is structured (type S).
unstructured_messageNo
ultimate_creditor_emptyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

A4.9/5.0
Behavior5/5

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

Discloses important runtime behavior beyond annotations: it returns structured findings with source strings, derives proposed structured addresses from combined addresses, and routes to a free POST endpoint. No conflict with readOnly/idempotent annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but organized with USE WHEN, DO NOT USE, RETURNS, IMPORTANT, and COST sections. A few phrases are slightly redundant, but most sentences carry essential operational detail, and the structure aids scanning.

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?

The description fully covers the tool's inputs, outputs, special transformations, routing, cost, and operational context, including how to relay findings and what to do with combined addresses. Nothing needed for correct invocation appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers the single payload parameter well, and the description adds meaning by noting it is the QR-code text starting with SPC and contains line breaks. Together they provide complete parameter understanding.

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?

Clearly identifies the tool's function: checking a Swiss QR-bill payload for well-formedness, reference/IBAN compatibility, and address structure. It distinguishes itself from related tools like validate_iban by explicitly stating what it does not do.

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?

Provides explicit when-to-use guidance (before paying or issuing a QR-bill), when-not-to-use guidance (for bank-account lookup use validate_iban), and contextual rules such as the 2025/2026 transition dates for address types.

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