Skip to main content
Glama

qrtap_create_code

Creates a managed QR code that encodes a stable short URL while allowing the destination to be edited later, so printed codes never need replacement.

Instructions

Create ONE managed QR code on QRTap. Returns the code object: id, short_url (the stable link the QR actually encodes — printing this once is safe because it never changes), png_url/svg_url for the rendered artifact, plus the label/group/external_ref you set. The destination behind the code is editable forever via qrtap_change_destination, so the printed sticker never has to be reissued. For more than a handful of codes at once use qrtap_create_codes_bulk instead — it is one request rather than N.

Input Schema

NameRequiredDescriptionDefault
urlYesDestination URL the code should redirect to (http/https, max 2048 chars).
groupNoAnalytics bucket for this code, one of: partner | equipment | event_menu | bag_insert | training. Codes sharing a group can be totalled in one call with qrtap_group_stats, so set it whenever a code belongs to a batch (a branch, a partner, an event).
titleNoHuman-readable label shown in the owner's cabinet (max 160 chars). Not visible to the person scanning. Defaults to 'Код'.
external_refNoYour own identifier for this code (branch code, SKU, partner id, table number), max 200 chars. Two things depend on it: creation is idempotent by external_ref, so re-running the same call returns the existing code instead of minting a duplicate; and qrtap_list_codes can look a code up by it later. Always set it for batches — it is what makes a retry safe.
design_template_idNoOptional branded design template id (UUID) from qrtap_list_design_templates. Applies the organization's colour and centre logo to the rendered QR.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.4

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the return shape (id, short_url, png_url/svg_url), the critical immutability guarantee that short_url never changes, and that creation is idempotent by external_ref so retries are safe. It stops short of auth/permission requirements, rate limits, and error behavior on invalid URLs, which keeps it off a 5.

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?

Three sentences, front-loaded with the cardinality constraint, then the return contract, then the sibling routing. No filler; the parenthetical about printed stickers never being reissued is the payload that justifies the whole tool's existence.

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?

No output schema exists, and the description compensates by enumerating the returned fields (id, short_url, png_url/svg_url, plus echoed label/group/external_ref). Combined with 100% schema coverage and the bulk-tool routing, an agent has everything needed to call this correctly and interpret the result.

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 schema already explains url constraints, group bucketing, title default, external_ref idempotency, and design_template_id provenance. The description repeats the external_ref/idempotency idea in conceptual terms but adds no syntax, formats, or constraints beyond what the schema states, so the baseline 3 is appropriate.

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 with an explicit cardinality constraint ('Create ONE managed QR code on QRTap') and immediately distinguishes itself from qrtap_create_codes_bulk. An agent can tell exactly what this tool mints and how it differs from the sibling bulk tool without opening either schema.

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

Usage Guidelines5/5

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

Explicit routing: single code here, 'for more than a handful of codes at once use qrtap_create_codes_bulk instead — it is one request rather than N.' It also points to qrtap_change_destination for the later edit workflow and to qrtap_list_codes for lookup by external_ref, so the agent knows both the boundary condition and the adjacent operations.

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