QR Code Creator

Change where a QR code points

update_destination

DestructiveIdempotent

Pro only ($9/month), and needs an API key whose owner has Pro and owns the code. Points a "redirect" QR code at a new URL without reprinting it. Without a key, tell your user they can do this on QRCodeCreator.app after claiming the code and subscribing (see start_pro_subscription).

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": {
      "id": "<id>",
      "url": "<url>"
    },
    "name": "update_destination"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	QR code ID, e.g. "QR-ABCD1234EF". Must be a "redirect" code to have any effect on scans.
`url`	Yes	The new destination, an http or https URL.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds the crucial behavioral qualifier that only "redirect" codes are affected and that non-redirect codes get no scan effect. It also discloses the auth/entitlement requirement, which annotations cannot express. What it does not spell out is that the previous destination is overwritten/lost, though the destructive annotation and "new URL" phrasing imply it.

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?

Three sentences, no filler, and the entitlement gate is up front so an agent won't burn a failing call. The final sentence is long and mixes the fallback instruction with the subscription cross-reference, but every element is actionable.

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 two-parameter mutation with full schema coverage and rich annotations, the description covers the remaining gaps: entitlement prerequisites, effect scope (redirect codes only), and the no-key fallback. No output schema exists and none is needed for a pointer update.

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 coverage is 100% and the schema already documents both fields, including the redirect-code constraint on `id` and the http/https constraint on `url`. The description restates the redirect constraint but adds no new syntax, format, or edge-case guidance for the parameters, so baseline 3 applies.

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 names a specific verb and resource: it "points a 'redirect' QR code at a new URL without reprinting it." The restriction to "redirect" type codes and the contrast with printing a new code separate it cleanly from create_qr_code.

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?

It states the gate explicitly (Pro subscription, API key owned by a Pro user who owns the code) and gives a concrete fallback when no key is available: have the user claim the code and subscribe on QRCodeCreator.app, routed via start_pro_subscription. That is an explicit when/when-not with a named alternative.

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

All QR Code Creator 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?