Skip to main content
Glama

Zovo QR Code Maker

Generate QR code

generate_qr_code
Read-onlyIdempotent

Use this when the user wants a QR code: for a website link, plain text, an email, a phone number, an SMS, a contact card (vCard), or a calendar event. Returns the code as SVG with PNG and SVG download links, plus scan warnings (low contrast, high density) and an optional minimum print size. Plain text and SMS text are limited to 1,500 characters; URLs to 2,000; encoded content must fit the QR byte capacity (1,273–2,953 bytes depending on error correction). Generates static codes only; it does not shorten links, track scans, or make Wi-Fi codes. Do not use for barcodes (EAN/UPC/Code 128).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kind": "<kind>"
    },
    "name": "generate_qr_code"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoFor kind=event: end as local date-time YYYY-MM-DDTHH:MM, e.g. 2026-11-05T21:00. For an all-day event, the last day YYYY-MM-DD (inclusive).
urlNoFor kind=url: the http or https web address, e.g. https://example.com/menu. https:// is added if missing.
bodyNoFor kind=email: prefilled body, e.g. Hi, I would like to book a table for 4.
kindYesWhat the code should do when scanned: url (open a website), text (show plain text), email (compose an email), phone (call a number), sms (start a text message), contact (save a vCard contact), event (add a calendar event). Example: url.
nameNoFor kind=contact: full name, e.g. Jane Doe. For kind=event: event title, e.g. Launch party.
textNoFor kind=text: the text to encode, e.g. Table 12 - ask for the specials. For kind=sms: the prefilled message, e.g. JOIN.
emailNoFor kind=email: recipient address, e.g. hello@example.com. For kind=contact: the contact's email.
phoneNoFor kind=phone, sms, or contact: phone number, ideally in international format, e.g. +1 415 555 0100. Letters (1-800-FLOWERS) are converted to keypad digits; an extension such as "ext. 23" is dialled after a pause.
startNoFor kind=event: start as local date-time YYYY-MM-DDTHH:MM, e.g. 2026-11-05T18:30, or a date YYYY-MM-DD for an all-day event. Times are local to the phone that scans the code.
titleNoFor kind=contact: job title, e.g. Head of Sales.
subjectNoFor kind=email: subject line, e.g. Table booking.
websiteNoFor kind=contact: website URL, e.g. https://example.com.
locationNoFor kind=event: venue or address text shown in the calendar entry, e.g. Pier 39, San Francisco.
backgroundNoBackground colour as hex, e.g. #FFFFFF (default).
foregroundNoCode (module) colour as hex, e.g. #111111 (default). Dark colours scan best. Basic colour names like navy or black also work.
organizationNoFor kind=contact: company or organization, e.g. Acme Inc.
error_correctionNoDamage tolerance, e.g. M: L 7%, M 15% (default), Q 25%, H 30%. Use H for printed codes that may get scuffed or carry a logo sticker.
scan_distance_cmNoOptional distance in centimetres from which people will scan the printed code, e.g. 300 for a poster across a room; used to recommend a minimum print size.

Output Schema

NameRequiredDescriptionDefault
svgYes
kindYes
modulesYes
payloadYes
requestYes
summaryYes
versionYes
warningsYes
downloadsYes
backgroundYes
foregroundYes
contrast_ratioYes
error_correctionYes
min_print_size_cmYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds substantial context beyond that: static-only generation, no link shortening or scan tracking, content-length and byte-capacity limits, returned SVG/PNG artifacts, scan warnings, and optional minimum print-size recommendations.

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 five dense sentences, front-loaded with the primary use case, followed by output details, capacity constraints, static-code limitations, and exclusions. Every sentence contributes relevant invocation guidance without filler.

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 an 18-parameter tool with rich schema coverage and an output schema, the description supplies the missing context an agent needs: supported kinds, exclusions, content limits, static-only behavior, and what output artifacts to expect. Return structure is already covered by the output schema, so the description does not need to duplicate it.

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

Parameters4/5

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

Schema description coverage is 100%, so the schema already carries the parameter-level details; the description nevertheless adds meaningful cross-cutting semantics such as 1,500-character limits for text/SMS, 2,000-character URL limits, and QR byte-capacity constraints that are not fully captured by the schema's maxLength fields. It does not explain every parameter, but it adds useful meaning beyond the schema.

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?

The description states a specific verb and resource (generate QR codes) and enumerates supported content types, making the tool's purpose unmistakable. It scopes out barcodes and Wi-Fi codes, but it does not explicitly name or distinguish itself from the sibling generate_text_qr_code, so sibling differentiation is implied rather than explicit.

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?

It gives explicit usage guidance with 'Use this when the user wants a QR code' and clear exclusions ('Do not use for barcodes') plus limitations around link shortening, scan tracking, and Wi-Fi codes. It stops short of naming generate_text_qr_code as the alternative for plain-text-only needs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources