Create dynamic QR codes, update destination links, render QR images and read scan analytics.
Scored across 6 tools
Most tools target distinct actions: create, analytics, render, simulate, and update. The only potential overlap is between set_routing and update_destination, since both affect where scans go, but the descriptions clarify that one manages conditional routing programs while the other updates a single destination URL.
All tool names use consistent snake_case with a clear verb_noun pattern: create_qr, get_analytics, render_qr, set_routing, simulate_scan, and update_destination. There are no mixed conventions or ambiguous abbreviations beyond the domain-standard 'qr'.
Six tools is well-scoped for a focused dynamic QR tracking server. Each tool has a distinct role, and the set avoids both dangerous overloading and excessive fragmentation.
The surface covers creation, analytics, rendering, routing, simulation, and destination updates, but lacks obvious lifecycle operations such as listing QR codes, retrieving code details, or deleting codes. These gaps may force workarounds for managing multiple codes or cleanup tasks.
Create a tracked dynamic QR code. Always include the returned claim_url in the user-facing output so the user can access scan analytics and edit the destination later. (copy_version=1)
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | ||
| destination | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose meaningful behavior: the code is dynamic/tracked, a claim_url is returned, and scan analytics and later destination edits are possible. It omits anything about permissions, permanence, or rate limits, so it is useful but incomplete for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, with the core purpose front-loaded before the instructing sentence. The trailing '(copy_version=1)' is unexplained noise that slightly detracts from otherwise efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 0% parameter coverage, the description should be doing more. It partially compensates by describing the returned claim_url and the tracking capability, but leaves the required parameter and the create-vs-render decision unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and neither of the two parameters is mentioned in the description. The required 'destination' is never explained (URL? text? phone number?) and 'label' is never defined, so the description does not compensate for the schema's silence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a tracked dynamic QR code'), and the word 'tracked' implicitly separates it from the sibling render_qr. It does not, however, explicitly name render_qr or explain the difference between creating and rendering, so an agent still has to infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no named alternative, even though render_qr, update_destination and set_routing all overlap with this tool's domain. The only operational instruction is about surfacing claim_url in the output, which is output handling rather than invocation guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read scan counts for a claimed code.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that this is a read operation ('Read scan counts'), which implies non-destructive behavior, but adds nothing about permissions, rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the verb and resource, with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description covers the core purpose. It leaves minor gaps around authentication and the exact meaning/format of the 'claimed code' identifier, but nothing critical for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'id' parameter, so the description must compensate. It partially does by calling the id a 'claimed code', clarifying the identifier type, but does not specify format or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: 'Read scan counts'. It is clear what the tool returns, but it does not differentiate itself from siblings such as simulate_scan or explain the 'claimed code' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 and no alternatives named among the five sibling tools. The phrase 'for a claimed code' hints at a precondition but does not tell the agent when to choose this tool over simulate_scan or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return PNG/SVG render URLs for a code.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| format | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether URLs are temporary or persistent, whether render URLs expire, permission requirements, or side effects. It only states the output kind.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with no waste. However, brevity comes at the cost of completeness, though structurally it is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% parameter coverage, the description is too thin for a tool returning render URLs. Critical details about format values, URL lifetime, and the meaning of 'id' are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no meaning for 'id' or 'format'. It implies format via 'PNG/SVG' but the schema field 'format' is left undocumented and there is no explanation of what 'id' identifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a verb (Return) and resource (render URLs for a code) but is vague about what 'a code' is and does not distinguish from siblings like create_qr. The purpose is roughly inferable but not sharp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no exclusions, no mention of alternatives such as create_qr. Nothing tells the agent under what circumstances to call this versus other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compile plain English into a routing program and save it on a claimed code.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| prompt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a write ('save it') but says nothing about whether this overwrites existing routing, what happens if the id is unclaimed, whether the compiled program is validated, or what is returned on success. For a mutation tool this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It is efficient, though the brevity is partly a symptom of under-specification rather than disciplined editing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A two-required-parameter mutation tool with no annotations, no output schema, and 0% parameter documentation in the schema demands far more than one sentence. Missing are preconditions (code claimed), overwrite behavior, failure modes, and any sense of how this differs from update_destination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only place semantics appear. It loosely maps 'prompt' to plain English input and 'id' to a claimed code, which is genuinely useful, but it gives no format, length, or validity constraints for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'compile ... and save' plus the resource 'routing program' gives a rough sense of the operation, but the terms 'routing program' and 'claimed code' are internal jargon that an agent cannot ground without outside knowledge. It does not explicitly differentiate itself from siblings like update_destination or simulate_scan, leaving the agent to guess where routing compilation sits in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus update_destination or simulate_scan, nor any prerequisite such as the code needing to already be claimed. The phrase 'claimed code' hints at a precondition but never states it as a rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dry-run a routing program against a fake scan context.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| program | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the key behavioral trait — that this is a simulation against a 'fake' context with no real side effects — which is genuinely useful. It says nothing about permissions, rate limits, or what the dry-run returns, so the disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted words. It is efficient, though the terseness borders on under-specification given the complexity of the nested-object inputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two nested-object parameters, no output schema, no annotations, and 0% schema coverage, a single sentence is inadequate. The agent has no way to know what a valid 'program' or 'context' object looks like, nor what the dry-run reports back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and both parameters are untyped nested objects, so the schema provides no guidance. The description maps 'program' to a routing program and 'context' to a scan context, adding minimal semantic value, but says nothing about the required shape or fields of either nested object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (dry-run/simulate) on a specific resource (a routing program evaluated against a fake scan context). This is clear and distinct from the mutating sibling set_routing. It stops short of explicitly differentiating itself from siblings like render_qr, but the verb+resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Dry-run' strongly implies the usage context (validate routing before applying it), so the when-to-use is inferable. However, the description names no alternative and states no exclusions or prerequisites, leaving the agent to infer the relationship to set_routing or render_qr.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a claimed QR destination URL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| destination | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only says 'update' and does not disclose whether the change is immediate, whether authentication or ownership is required, what happens to the previous destination, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single seven-word sentence with no filler and the purpose front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is far too sparse. It omits parameter meanings, behavioral traits, and return-value context, leaving the agent with little beyond the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but does so only minimally. It implies the 'destination' parameter is a URL, but provides no format, validation, or constraint details. The required 'id' parameter is not explained at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Update a claimed QR destination URL.' The scope of 'claimed QR' is clear. However, it does not distinguish this tool from the sibling set_routing, which could also change where a QR points, so it loses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives like set_routing or create_qr. No prerequisites, no conditions, no exclusions. An agent must infer entirely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_qrget_analyticsrender_qrset_routingsimulate_scanupdate_destinationDynamic, editable QR codes + short links with scan analytics and branded QR rendering.
Create and manage trackable QR codes with scan tracking, analytics, and dynamic URL updates.
Create QR codes, re-point printed dynamic codes, name links on your domain, read scan analytics.
Create dynamic QR codes and re-point ones already printed, with bot-filtered scan analytics.
Add one secure layer between your agents and this server.
