Skip to main content
Glama

Create a QR code

create_qr_code

Create and save a QR code. mode "dynamic" encodes a short link whose destination can be changed later and whose scans are tracked (counts toward the plan limit); "static" encodes the content itself. Landing-page kinds (bio, business, pdf, app) must be dynamic. Call get_qr_code_image afterwards for the image.

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

Input Schema

NameRequiredDescriptionDefault
modeYes
nameYes
designNo
contentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / content / type
      Added value: +"object"
    • addedInput schema / properties / design / type
      Added value: +"object"
    • addedInput schema / properties / mode / type
      Added value: +"string"
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare write, non-idempotent, open-world, non-destructive, so the description's job is to add context beyond that — and it does: dynamic codes are mutable and scan-tracked, count against the plan's dynamic limit, while static codes are immutable and untracked. It does not mention what the call returns (e.g., an id needed for later calls), which an agent would want.

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 short sentences, front-loaded with the action, then the mode trade-off, then the next-call hint. No filler and every clause carries operational 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 4-parameter write tool with deep nested content schemas and no output schema, the description covers the decisive choices and the follow-up call. The one gap is that it never says the created code's identity or fields are returned, which matters for chaining into get_qr_code_image and update_qr_code.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Top-level schema description coverage is 0%, so the description must carry meaning, and it explains the most consequential parameter, mode, in depth including the plan-limit consequence. It also states a cross-parameter constraint (landing-page kinds force dynamic) that no single schema field expresses. The name and design parameters get no mention, leaving some gap.

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 ("Create and save a QR code") and immediately disambiguates from siblings by saying the image is fetched via get_qr_code_image. An agent can tell this is the creation entry point and not the read/render tool.

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 real decision guidance: dynamic vs static semantics, and the hard rule that landing-page kinds (bio, business, pdf, app) must be dynamic. It also tells the agent what to do next (call get_qr_code_image for the image). It does not contrast with update_qr_code or make_qr_code_image for the 'already exists' or 'just need an image' cases, so not a full 5.

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.

Resources