Skip to main content
Glama

generate_qr_decoration

Create a QR code heightmap for embossing onto 3D models, and check whether the code will still scan at your intended print size.

Instructions

Generate a QR code heightmap for embossing onto 3D models (Business). Opens Kiln's interactive inline 3D stage on the result (orbit/zoom panel in MCP Apps hosts; hosted sessions add a browser stage link).

INLINE 3D STAGE: on success this tool opens Kiln's interactive 3D stage — an inline viewer panel the user can orbit, zoom, and turn over — in hosts that render MCP Apps panels (Kiln's hosted connection attaches a browser stage link for hosts that don't). Oversized meshes are decimated automatically for the stage; the PNG preview is the floor, not the whole experience.

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>",
      "output_dir": "<output_dir>"
    },
    "name": "generate_qr_decoration"
  }
}

Input Schema

NameRequiredDescriptionDefault
contentYesWhat the code encodes -- a URL or any text.
nozzle_mmNoNozzle diameter the scan check is judged for. Leave it out to use the nozzle on record for your printer (else 0.4); the answer's ``nozzle`` block says which size it used.
output_dirYesFolder the heightmap (``qr_heightmap.dat``) is written to.
target_size_mmNoHow wide the code will be printed, in mm. Give it and the answer says whether the code will still scan at that size; leave it at 0 to get the heightmap alone. Default: 0.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • addedInput schema / properties / content / description
      Added value: +"What the code encodes -- a URL or any text."
    • addedInput schema / properties / nozzle_mm / description
      Added value: +"Nozzle diameter the scan check is judged for.  Leave it out to use the nozzle on record for your printer (else 0.4); the answer's ``nozzle`` block says which size it used."
    • addedInput schema / properties / output_dir / description
      Added value: +"Folder the heightmap (``qr_heightmap.dat``) is written to."
    • changedInput schema / properties / target_size_mm / description
      Previous value: -"Default: 0.0."New value: +"How wide the code will be printed, in mm.  Give it and the answer says whether the code will still scan at that size; leave it at 0 to get the heightmap alone. Default: 0.0."
  2. Addedv1.5.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations only declare it is a non-read-only, non-destructive, closed-world call. The description adds real behavior beyond that: it opens an inline 3D stage, decimates oversized meshes automatically, and produces a PNG preview plus heightmap. It still omits whether the heightmap file overwrites an existing qr_heightmap.dat in output_dir and what the nozzle/scan-check result block contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the 'INLINE 3D STAGE' paragraph largely restates the second sentence of the opening line (stage opens, orbit/zoom, browser link for hosts). Only the decimation and PNG-preview notes are new, so roughly half the text is redundant.

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

Completeness3/5

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

For a 4-param generator with no output schema, the description covers the side effects and the interactive stage well, which is the non-obvious part. It is still thin on what the caller receives back (heightmap path, scan-check verdict, preview) and gives no guidance on choosing target_size_mm, which is the one parameter with a meaningful decision behind it.

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 the parameters (content, nozzle_mm, target_size_mm, output_dir) are already fully documented. The description adds nothing about them — notably it never explains that target_size_mm triggers the scannability check or that nozzle_mm defaults to the printer on record — so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and artifact: 'Generate a QR code heightmap for embossing onto 3D models.' An agent can tell this creates a heightmap rather than applying a QR to an existing product mesh, but it never names the neighbouring tools (add_qr_to_product, generate_* decoration generators) that it should be distinguished from.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance. The '(Business)' tag hints at a tier gate and 'for embossing onto 3D models' implies a context, but nothing tells the agent whether to reach for this instead of add_qr_to_product or a general decoration tool.

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