Skip to main content
Glama

Design a QR code

design_qr
Read-onlyIdempotent

Design a QR code for any content type (link, Wi-Fi, contact, email, SMS, WhatsApp, payments, social profiles and more) with the style you choose: colors and gradients, dot, eye and eye center shapes, a built-in call-to-action frame with its text or a custom frame spec, a border, a logo icon or your own uploaded logo (logo_file_id, with an API key), margin and error correction. Can start from a built-in preset or a community item. Validates the content like the QRdx editor, checks the scan score with the editor's scan check and repairs the style until it is Great (at most 3 repairs, then a classic black-on-white code). Returns the score, what was changed and why, the style JSON (qrdxStyle, ready for save_template and generate_qr_code), a playground_url that opens the design in the QRdx editor, a PNG and the SVG. Call list_options first for the accepted values.

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": {
      "content": "<content>"
    },
    "name": "design_qr"
  }
}

Input Schema

NameRequiredDescriptionDefault
sizeNoWidth of the code in pixels (128-1024); frames add to it
styleNoHow the code looks. Leave options out for defaults (or the preset's or community item's): eyes and eye centers follow the dot color, square shapes, margin 4, level Q, no frame.
presetNoStart from a built-in QRdx theme by id (list_options lists them); style options you set win over it
contentYesWhat the code opens: a type and its fields (list_options lists the fields of every type)
include_svgNoReturn the SVG markup (often 50-150 KB)
logo_file_idNoYour own logo: an image you uploaded to QRdx (PNG or JPEG, up to 1 MB), by file id. Needs the workspace's API key on this connection (Authorization: Bearer qrdx_…).
community_itemNoStart from a community theme or frame by id, such as frame:wifi-card (search_community finds them); style options you set win over it

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?

Discloses behavior the annotations cannot: content validation, a scan-score check, an automatic repair loop capped at 3 attempts, and the fallback to a classic black-on-white code on failure. It also flags the API-key requirement for logo_file_id and details the full return payload (score, change log, style JSON, playground_url, PNG, SVG), so the agent knows what it gets back and that its input may be silently altered.

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?

Purpose and the validation/repair behavior are front-loaded, and the trailing sentences on returns and the list_options prerequisite each earn their place. The opening sentence is an overlong run-on catalog of style options that partly duplicates the schema, which costs a little efficiency.

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 tool with seven parameters, deep nested objects, no output schema and no annotations about returns, the description covers what is missing: the repair/fallback policy, the full shape of the response, the auth prerequisite, and the pointer to list_options for enums and per-type fields. An agent could call this correctly without further exploration.

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% and the nested style/content objects are exhaustively documented in the schema itself, so the schema carries most of the meaning. The description adds only two things beyond it: the API-key requirement tied to logo_file_id and a high-level inventory of styleable features (colors, dot/eye shapes, frames, logo, margin, error correction). That is useful framing but not parameter-level detail.

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 and resource ('Design a QR code') and immediately bounds the scope: any content type, styled output, validated and auto-repaired. It also positions itself in the pipeline by naming save_template and generate_qr_code as the consumers of the returned qrdxStyle, which distinguishes it from those siblings.

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?

Gives an explicit prerequisite ('Call list_options first for the accepted values') and explains the two starting modes (built-in preset or community item, with style options winning). It never states outright when to prefer this over generate_qr_code, though the 'style JSON ready for save_template and generate_qr_code' phrasing implies the design-first role.

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.