QR Branding

Generate a QR code (manual)

qr_generate

Read-onlyIdempotent

Generate fully branded QR codes with explicit control over colors, shapes, logos, captions, and output formats when the design is already known.

Instructions

Generate a fully branded QR code with explicit control over colors, module/finder shapes, logo, caption, and output format. Use this when the user already knows the design they want.

Input Schema

Name	Required	Description
`text`	No	Optional caption rendered below the QR (e.g. a slogan).
`content`	Yes	The text or URL the QR will encode. Required.
`logoUrl`	No	Public HTTPS URL of a logo image to embed at the center.
`eccLevel`	No	Error-correction level (L=7%, M=15%, Q=25%, H=30%). Higher levels survive more damage but are denser.
`frameText`	No	Label inside the frame, max 40 characters, any language (e.g. "Scan me", "View the menu"). Defaults to "Scan me".
`fileFormat`	No	Output format. Defaults to "png".
`frameColor`	No	Frame colour in hex, also the label background. Defaults to "#000000".
`frameStyle`	No	Call-to-action frame around the whole QR with a short label. Never covers the QR or its quiet zone.
`moduleShape`	No	Shape of the small modules in the QR matrix.
`outputWidth`	No	Output width in pixels (raster) or viewport units (svg). 64-4096.
`outputHeight`	No	Output height in pixels (raster) or viewport units (svg). 64-4096.
`primaryColor`	No	Foreground/module color in hex (e.g. "#000000" or "#0a84ff").
`frameTextColor`	No	Frame label colour in hex. Defaults to "#FFFFFF".
`backgroundColor`	No	Background color in hex (e.g. "#ffffff"). Use "transparent" for no background.
`additionalConfig`	No	Escape hatch: any other QrConfig field the engine accepts (gradient stops, dot rotation, etc.). Merged on top of the structured fields above.
`finderInnerShape`	No	Shape of the inner dot of the three corner finder patterns.
`finderOuterShape`	No	Shape of the outer ring of the three corner finder patterns.

Output Schema

Name	Required	Description
`format`	Yes	File format the engine rendered: png, svg, jpg, webp or pdf.
`content`	No	The text or URL the QR encodes, when the call set it.
`filePath`	No	PDF in the stdio package only: local temp file the PDF was written to.
`mimeType`	No	MIME type of the rendered file (the engine's contentType).
`sizeBytes`	No	Size of the rendered file in bytes, as reported by the engine.
`resourceUri`	No	PDF on the remote server only: URI of the embedded resource block that carries the file.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.4Oct 18, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds little beyond that: no note on whether the logoUrl must be publicly reachable, how additionalConfig merges/overrides, or generation latency, and the output schema already covers returns.

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 sentences, no redundancy, with the capability scope front-loaded and the selection condition second. Nothing could be removed without losing information.

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

Completeness4/5

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

For a 17-parameter tool the description is short, but the 100% schema coverage, output schema, and full annotation set carry the detail. It conveys what the tool produces and when to pick it; the only real gap is not naming the AI sibling explicitly.

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 every one of the 17 parameters is already documented in the schema, including enums, ranges, and defaults. The description only groups them at a high level (colors, shapes, logo, caption, format) without adding syntax or precedence detail, which is the expected baseline when the schema does the heavy lifting.

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) with the scope of control enumerated: colors, module/finder shapes, logo, caption, output format. The 'manual' framing plus 'explicit control' implicitly separates it from qr_generate_ai, so an agent can route between the two without opening schemas.

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?

'Use this when the user already knows the design they want' gives a clear selection condition and implicitly contrasts with the AI-driven sibling. It stops short of naming qr_generate_ai as the alternative or stating exclusions, so it is good context rather than full routing guidance.

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

Deploy Server