qart.uk QR studio

get_qr_matrix

Return the actual QR MODULE GRID for a payload — the black/white matrix, plus a per-module map of which modules are function patterns (finder, separator, timing, alignment, format info, version info, dark module) and which carry data. Both come back as one row string per row. Costs nothing, mints nothing, stores nothing.

Use this when you are going to RENDER or transform a QR yourself: dithering a photo into it, drawing it as an SVG, laying it out for print, or reasoning about which modules are safe to alter. The function-pattern map is the point — any technique that paints over a QR has to know which modules a scanner uses to FIND the code (finder, timing, alignment) versus which merely carry bits.

Do NOT use it to check whether a payload fits — preview_qr_encoding is smaller and answers that. Do NOT use it to get a qart.uk product: this is a plain standards QR, with no artwork, no scan verdict and no alias behind it. The matrix is canonical and untransformed: invert, rotation, mirror and any subpixel scaling are yours to apply afterwards.

Input Schema

TableJSON Schema

Name	Required	Description
`ecc`	No	Error correction level. Defaults to H, which is what any paint-over-the-code technique needs.
`end`	No	For 'event': end datetime.
`lat`	No	For 'geo': latitude.
`lng`	No	For 'geo': longitude.
`org`	No	For 'vcard': organization.
`url`	No	For 'url': the destination. For 'vcard'/'mecard': the website.
`auth`	No	For 'wifi': security type. Defaults to WPA.
`body`	No	For 'mailto': message body.
`mask`	No	Which of the 8 standard mask patterns to apply. 'auto' (default) picks the lowest-penalty one, exactly as the encoder in the browser does. All 8 are legal and scan identically; they differ only in how the light and dark modules are laid out, which is worth pinning when you are fitting a picture to the grid.
`name`	No	For 'vcard'/'mecard': full name.
`ssid`	No	For 'wifi': network name.
`text`	No	For 'text': the literal text.
`email`	No	Email address, for 'vcard'/'mecard'/'mailto'.
`phone`	No	Phone number, for 'vcard'/'mecard'/'tel'/'sms'/'whatsapp'.
`start`	No	For 'event': start datetime (YYYY-MM-DDTHH:MM).
`title`	No	For 'vcard': job title. For 'event': event title.
`allDay`	No	For 'event': all-day (DATE values).
`amount`	No	For 'paypal': optional amount.
`handle`	No	For social kinds (instagram, twitter, youtube, facebook, tiktok, linkedin, paypal): handle or profile URL.
`hidden`	No	For 'wifi': hidden network.
`address`	No	For 'vcard': postal address.
`message`	No	For 'sms'/'whatsapp': message text.
`subject`	No	For 'mailto': subject line.
`version`	No	Force a QR version (1-40, size 21-177 modules). Omit for the smallest that fits. Pinning BELOW the fit is impossible and is raised to the fit, matching the Studio.
`location`	No	For 'event': location.
`password`	No	For 'wifi': network password.
`username`	No	For 'telegram': username or t.me URL.
`description`	No	For 'event': description.
`payloadKind`	No	What the code should contain. Defaults to url.

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedAug 17, 2026

addedInput schema / properties / allDay

Added value: +{
+  "description": "For 'event': all-day (DATE values).",
+  "type": "boolean"
+}

addedInput schema / properties / amount

Added value: +{
+  "description": "For 'paypal': optional amount.",
+  "type": "string"
+}

addedInput schema / properties / description

Added value: +{
+  "description": "For 'event': description.",
+  "type": "string"
+}

addedInput schema / properties / end

Added value: +{
+  "description": "For 'event': end datetime.",
+  "type": "string"
+}

addedInput schema / properties / handle

Added value: +{
+  "description": "For social kinds (instagram, twitter, youtube, facebook, tiktok, linkedin, paypal): handle or profile URL.",
+  "type": "string"
+}

addedInput schema / properties / location

Added value: +{
+  "description": "For 'event': location.",
+  "type": "string"
+}

changedInput schema / properties / message / description

Previous value: -"For 'sms': message text."New value: +"For 'sms'/'whatsapp': message text."

changedInput schema / properties / payloadKind / enum

Previous value: -[
-  "url",
-  "qart_code",
-  "text",
-  "wifi",
-  "vcard",
-  "mecard",
-  "mailto",
-  "tel",
-  "sms",
-  "geo"
-]New value: +[
+  "url",
+  "qart_code",
+  "text",
+  "wifi",
+  "vcard",
+  "mecard",
+  "mailto",
+  "tel",
+  "sms",
+  "geo",
+  "whatsapp",
+  "telegram",
+  "event",
+  "instagram",
+  "twitter",
+  "youtube",
+  "facebook",
+  "tiktok",
+  "linkedin",
+  "paypal"
+]

changedInput schema / properties / phone / description

Previous value: -"Phone number, for 'vcard'/'mecard'/'tel'/'sms'."New value: +"Phone number, for 'vcard'/'mecard'/'tel'/'sms'/'whatsapp'."

addedInput schema / properties / start

Added value: +{
+  "description": "For 'event': start datetime (YYYY-MM-DDTHH:MM).",
+  "type": "string"
+}

changedInput schema / properties / title / description

Previous value: -"For 'vcard': job title."New value: +"For 'vcard': job title. For 'event': event title."

addedInput schema / properties / username

Added value: +{
+  "description": "For 'telegram': username or t.me URL.",
+  "type": "string"
+}

First observedAug 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries full burden and exceeds it: 'Costs nothing, mints nothing, stores nothing' discloses side effects; 'Both come back as one row string per row' describes return format; 'canonical and untransformed' explains transformations are left to the caller. This goes far beyond a minimal 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?

The three-paragraph structure front-loads the purpose, then provides usage context and exclusions. Every sentence earns its place: the function-pattern explanation, the two 'Do NOT' exclusions, and the canonical/untransformed note are all essential and non-redundant. No fluff.

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?

Given 29 parameters, no output schema, and no annotations, the description is remarkably complete. It explains the output format (row strings), the semantic distinction between function patterns and data modules, when to use, when not to use, and the untransformed nature of the matrix. An agent has enough context to invoke correctly.

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?

The input schema has 100% coverage with per-parameter descriptions, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema; it focuses on output and usage. It does not compensate for any gaps because there are none, but it also doesn't elevate understanding of parameter semantics beyond what the schema already offers.

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?

The description opens with a specific verb and resource: 'Return the actual QR MODULE GRID for a payload — the black/white matrix, plus a per-module map...'. It clearly distinguishes from siblings by contrasting with preview_qr_encoding and qart.uk products, making the purpose unmistakable.

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?

Explicitly states when to use ('when you are going to RENDER or transform a QR yourself') and when not to use ('Do NOT use it to check whether a payload fits — preview_qr_encoding... Do NOT use it to get a qart.uk product'). This is textbook-level usage guidance with named alternatives.

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

All qart.uk QR studio tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?