Skip to main content
Glama

OpenQR

by uk.openqr

update_dynamic_qr

Edit a dynamic QR code: change its destination, label, custom short link (slug), tags or folder. Pass only the fields you want to change. Requires an OpenQR API key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe dynamic code id.
pinNoPro: require a 4-digit PIN before the code redirects. Exactly 4 digits. Pass null to remove all protection.
slugNoCustom short-link back-half (oqr.to/<slug>): 3–48 letters, numbers or hyphens.
tagsNoReplace the code's tags (max 10).
labelNoNew label.
themeNoA saved theme id or name to restyle the code with.
statusNoPause the code (it stops resolving — scanners see an inactive page) or reactivate it. Free plan allows up to 3 active codes.
passwordNoPro: require this password before the code redirects (min 4 characters). Pass null to remove all protection.
folder_idNoMove into a folder id, or null to un-file.
lock_hintNoOptional hint shown on the unlock page, e.g. "Ask at the bar". Max 60 characters.
destinationNoNew http(s) URL.
pause_untilNoISO 8601 timestamp: schedule a pause until then (scanners see the inactive page; the code self-resumes at the deadline). Pass null to clear the schedule. Future timestamps only, active codes only.
ios_destinationNoApp links: iOS scanners follow this http(s) URL instead of destination (e.g. the App Store page). Pass null to clear. Applies to the plain redirect only.
android_destinationNoApp links: Android scanners follow this http(s) URL instead of destination (e.g. the Google Play page). Pass null to clear.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changed
    • addedInput schema / properties / android_destination
      Added value: +{
+  "description": "App links: Android scanners follow this http(s) URL instead of destination (e.g. the Google Play page). Pass null to clear.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedInput schema / properties / ios_destination
      Added value: +{
+  "description": "App links: iOS scanners follow this http(s) URL instead of destination (e.g. the App Store page). Pass null to clear. Applies to the plain redirect only.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedInput schema / properties / pause_until
      Added value: +{
+  "description": "ISO 8601 timestamp: schedule a pause until then (scanners see the inactive page; the code self-resumes at the deadline). Pass null to clear the schedule. Future timestamps only, active codes only.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  2. First observed

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the transparency burden. It does disclose partial-update behavior and API-key auth requirements, which is useful. However, it does not explain what the operation returns, whether changes take effect immediately, or any side effects or reversibility, so transparency is only partially addressed.

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 description is two sentences with no filler. It front-loads the core purpose, gives the most important usage rule, and states the auth requirement — every sentence earns its place.

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 tool with 14 optional parameters and no output schema, the description provides only the essential editing context and auth requirement. The schema covers parameters well, but the description lacks guidance on what to expect back from the call and does not clarify edge cases such as preserving unspecified fields, though 'pass only the fields you want to change' partially implies 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 are already well documented in the schema. The description adds partial-update context and mentions a subset of parameter names, but does not add substantial meaning beyond the schema.

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?

The description clearly states it edits a dynamic QR code and names several concrete editable fields (destination, label, slug, tags, folder), making the resource and action unambiguous. It does not explicitly differentiate itself from sibling tools, but the edit/update semantics are clear against create/delete/list siblings.

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

Usage Guidelines3/5

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

It gives practical partial-update guidance ('Pass only the fields you want to change') and the prerequisite that an OpenQR API key is required. However, it does not explicitly say when to prefer this tool over alternatives like create_dynamic_qr or bulk_create_dynamic_qr, leaving that to inference from the tool name and siblings.

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

All OpenQR toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation5/5

Each tool targets a distinct operation on a specific resource: static vs dynamic QR creation, single vs bulk, subdomain management, folder/theme CRUD, scan statistics. No two tools have overlapping purposes; even similar verbs like create_dynamic_qr and bulk_create_dynamic_qr are clearly differentiated by cardinality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., create_dynamic_qr, get_scans, set_subdomain). Compound verbs like bulk_create are standard. No mixing of styles or irregular names.

Tool Count5/5

17 tools is well-scoped for a QR code management server. It covers creation (static, dynamic, bulk), update, delete, retrieval, listing, scan stats, subdomain management, folders, and themes—each tool serves a clear purpose without bloat.

Completeness4/5

The toolset provides full CRUD for dynamic QR codes and subdomain management, plus scan statistics, folder and theme management. Minor gaps: missing update operations for folders and themes, and no search/filter tool for codes. These are acceptable omissions given the API's typical usage.

Resources