Skip to main content
Glama
zovo-one

mcp-barcode

by zovo-one
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

SEPA payment QR code

qr_payment_sepa

Generate an EPC069-12 SEPA payment QR code that euro banking apps can scan. Supply amount and reference; beneficiary IBAN and name default to the shared business profile.

Instructions

Call this tool for an EPC069-12 payment QR a euro banking app can scan. Amount and reference are enough: the beneficiary IBAN and name default to the shared business profile, never asked for.

Input Schema

NameRequiredDescriptionDefault
bicNoBeneficiary BIC. Optional under EPC version 002
ibanNoBeneficiary IBAN. Defaults to the iban in the shared business profile (set once with the invoice server's business_set). Checked with ISO 7064 mod 97 and refused if it does not validate
nameNoBeneficiary name, up to 70 characters. Defaults to the name in the shared business profile
sizeNoPNG width in pixels, 32 to 4000 (default 300). SVG scales without it
amountNoAmount in EUR, 0.01 to 999999999.99. Leave out and the payer types it
formatNosvg (default, free) or png (Pro)
marginNoQuiet zone in modules, default 4, which is what the QR standard requires
purposeNoFour-letter ISO 20022 purpose code, for example GDDS
currencyNoEUR only; any other value is refused, because EPC encodes a SEPA credit transfer
out_pathNoWhere to write the file. SVG is returned inline when this is left out; PNG always needs it
overwriteNoReplace out_path if it already exists (default false)
referenceNoStructured creditor reference (RF...), up to 35. Use this OR remittance, never both
remittanceNoFree payment text, up to 140 characters, for example an invoice number
error_correctionNoL 7%, M 15% (default), Q 25%, H 30% of the code recoverable when damaged

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare non-read-only, non-destructive, non-idempotent and closed-world, so the safety profile is covered. The description adds that beneficiary details come from the shared business profile, but never mentions that the tool writes files when out_path is set (and needs out_path for PNG), which is the main side effect an agent should know about.

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?

Two short sentences, front-loaded with the trigger condition, and no filler. Everything stated earns its place.

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

Completeness3/5

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

Given 14 parameters and no output schema, the description is thin: it omits that SVG is returned inline unless out_path is given and that PNG requires out_path, and it leaves the invoice_payment_qr overlap unresolved. The rich schema compensates for parameter detail, but the tool-choice and output story is incomplete.

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 coverage is 100%, so every one of the 14 parameters, including defaults, ranges, enums and the validation/refusal rules, is already documented in structured fields. The description's only parameter claim (IBAN/name default to the business profile) repeats the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: an EPC069-12 payment QR a euro banking app can scan. That is concrete and distinguishable from qr_wifi/qr_vcard/barcode_create, but it does not explain how it differs from the sibling invoice_payment_qr, which sounds like the same job.

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

Usage Guidelines3/5

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

'Amount and reference are enough' gives implied context, and the note that IBAN/name default to the business profile tells the agent not to ask for them. But there is no explicit when-to-use/when-not guidance, especially against invoice_payment_qr, which is the most likely source of a wrong 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