Skip to main content
Glama
Sign In
zola-mcp

zola-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

preview_qrcode

Read-only

Generate a QR-code PNG for an invitation so you can inspect the image before placing it on a wedding card; returns the PNG or a download link if it exceeds 10 MiB.

Instructions

Generate a QR-code PNG for an invitation. Returns the image so it can be inspected (or, if it is ever over 10 MiB on a hosted install, a signed, expiring download link). Use set_card_project_qrcode to actually place it on a card.

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": {
      "url": "<url>"
    },
    "name": "preview_qrcode"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesURL the QR code will resolve to
enabledNoWhether the QR code is enabled. Default: true.
url_typeNoCUSTOM (default) | WEDDING_WEBSITE | WEDDING_WEBSITE_RSVP
dimensionNoSMALL | MEDIUM (default) | LARGE

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observedv1.4.2

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, yet the description adds real behavioral detail beyond them: the return is a PNG image for inspection, with a fallback to a signed, expiring download link when the payload exceeds 10 MiB on a hosted install. It does not mention rate limits, caching, or whether any artifact is persisted, so it stops short of full disclosure.

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 tight sentences with zero waste: purpose and return behavior first, sibling routing second. The parenthetical size caveat is subordinate and does not bury the main point.

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 read-only preview tool with no output schema, the description covers what matters: what is produced (a PNG), how it is delivered (inline image, or a signed expiring link in the large-payload case), and where the output goes next (the sibling setter). Nothing needed to call it correctly is missing.

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 description coverage is 100%, so url, enabled, url_type, and dimension are already documented with defaults. The description adds only framing ("for an invitation") and does not explain how url_type or dimension affect the rendered output, so baseline 3 applies.

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?

States a specific verb+resource ("Generate a QR-code PNG for an invitation") and immediately distinguishes itself from the sibling that consumes the result ("Use set_card_project_qrcode to actually place it on a card"). An agent can tell this is a preview/rendering tool, not a mutation, without consulting the schema.

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?

Explicitly routes the agent: use this to generate and inspect the image, use set_card_project_qrcode to actually place it on a card. Clear context on why one would call it, though there is no guidance on when a preview is unnecessary (e.g., re-previewing after changes).

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