Generate QR codes and create, edit & track dynamic (editable) QR codes with scan analytics — over a hosted MCP server plus a free REST API. 13 tools: generate_qr (no key), create/update/list/delete dynamic codes, get_scans, folders and themes. Free, no watermark.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 17 of 17 tools scored. Lowest: 3.1/5.
Most tools have clearly distinct purposes: QR creation (static vs dynamic, single vs bulk), management (get/list/update/delete), and supporting resources (folders, themes, subdomain, scans). The only potential confusion is between create_dynamic_qr and bulk_create_dynamic_qr, but the bulk variant is clearly described as creating up to 200 at once.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_dynamic_qr, list_folders, delete_theme, set_subdomain). The compound verbs like bulk_create and clear are still predictable and uniform across the set.
17 tools is on the higher end but still reasonable for a QR code management server that covers dynamic/static codes, folders, themes, subdomain branding, and scan analytics. Each tool corresponds to a distinct resource or action, so the count feels earned rather than padded.
The core QR code lifecycle is fully covered: create (single/bulk), read (get/list), update, delete. Supporting features like folders, themes, and subdomain management are also well represented. Minor gaps include lack of an update operation for themes and no way to fetch a single folder's details, but these are not critical to primary workflows.
bulk_create_dynamic_qrAInspectCreate up to 200 dynamic QR codes at once. Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
| codes | Yes | Codes to create. | |
| theme | No | A saved theme id or name applied to every code created. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions creation and API key requirement, omitting details on atomicity, partial failure, rate limits, or return value.
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 concise sentences, each providing necessary information: the action and a key requirement. No wasted words.
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?
Lacks output schema and does not describe return value or error handling. For a bulk creation tool, more context (e.g., atomicity, validation) is needed for an agent to use it correctly.
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?
Input schema covers 100% of parameters with descriptions. The tool description adds no further meaning beyond summarizing the overall action, so baseline score of 3 is appropriate.
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 clearly states 'Create up to 200 dynamic QR codes at once', specifying the verb and resource, and distinguishes from the sibling tool 'create_dynamic_qr' by mentioning batch capability.
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?
Implicitly suggests batch use vs. single creation via the phrase 'up to 200 at once', and mentions API key requirement, but does not explicitly state when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clear_subdomainAInspectRelease the branded subdomain. Codes stay live on the plain short link; only the {name}.oqr.to form stops resolving. The name becomes claimable by someone else. Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It transparently discloses the key behavior: codes remain live, only the subdomain form stops resolving, the name becomes claimable, and an API key is required. No contradictions.
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?
Three sentences, front-loaded with the main action, followed by consequences and prerequisite. Every sentence adds value with no redundancy.
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 tool with no params and no output schema, the description is complete: it explains the purpose, behavior, side effects, and authentication requirement. No critical information is missing.
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?
The tool has 0 parameters, so the schema is fully covered vacuously. Per guidelines, 0 params warrants a baseline of 4. The description adds relevant context about the subdomain name placeholder ({name}) but no parameter details are needed.
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 opens with a specific verb+resource: 'Release the branded subdomain.' It clearly distinguishes from siblings like set_subdomain by explaining the effect (subdomain stops resolving, codes stay live on plain link) and the consequence (name becomes claimable).
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?
The description implies the usage context: when you want to free up a branded subdomain without affecting short links. It doesn't explicitly name alternatives or when-not-to-use, but the action and its effects are clear enough to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_dynamic_qrAInspectCreate an editable (dynamic) QR code whose destination you can change later without reprinting. Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Optional label. | |
| theme | No | A saved theme id or name to style the code with. | |
| destination | Yes | The http(s) URL the code should point to. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full transparency burden. It discloses API key requirement and dynamic nature, but omits details on authentication method, rate limits, side effects, and return behavior. This partial coverage is adequate but not comprehensive.
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?
The description is extremely concise at two sentences with zero fluff. Every word adds value: 'editable (dynamic)', 'destination you can change later', 'without reprinting', and the API key requirement.
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?
Given no output schema, the description should hint at the return value (e.g., does it return a URL to the QR code?). It does not. Also, it lacks details on how the QR code is retrieved. For a simple creation tool, this gap reduces completeness.
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 100%, so the description adds no new parameter meaning beyond what schema descriptions already provide (e.g., destination is an http(s) URL). The description only reinforces that destination is changeable, which is already implied.
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 clearly states 'Create an editable (dynamic) QR code', specifying the verb (create) and resource (dynamic QR code). It distinguishes from static QR codes or other tools by emphasizing editability and the ability to change destinations later without reprinting.
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?
The description mentions the prerequisite 'Requires an OpenQR API key' and implies usage for scenarios needing future editability, but does not explicitly compare to siblings like generate_qr (static) or bulk_create_dynamic_qr. It provides clear context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_folderBInspectCreate a folder to organise codes. Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions the API key requirement, which is helpful. However, it does not disclose outcomes like whether the folder can be nested, if names must be unique, or any side effects. This is adequate but not thorough for a creation tool.
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?
The description is extremely concise with two sentences. It wastes no words and is appropriately sized for the tool's simplicity.
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?
Given no output schema and simple parameter set, the description should provide additional context like naming rules, return value, or error handling. It lacks this information, making it incomplete for an agent to use effectively.
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 the description does not add any meaning to the single 'name' parameter. It merely says 'Create a folder to organise codes' without explaining the parameter's format, constraints, or examples. The description fails to compensate for the lack of schema documentation.
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?
Description clearly states the action 'Create a folder' and the purpose 'to organise codes'. It distinguishes from sibling tools like 'delete_folder' by specifying the folder creation function. The verb and resource are explicit.
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?
Only mentions a prerequisite ('Requires an OpenQR API key') but provides no guidance on when to use this tool versus alternatives like 'bulk_create_dynamic_qr' or 'create_dynamic_qr'. No exclusion criteria or context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_themeBInspectSave a reusable style theme. style is a QR style object (fgColor, bgColor, dotType, cornerSquareType, etc.). Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| style | Yes | QR style JSON (colours, dot/corner shapes, logo, gradient, frame…). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions the API key requirement but omits any information about side effects (e.g., whether it overwrites existing themes), idempotency, rate limits, or response behavior. Minimal context for a creation tool.
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?
The description is extremely concise with two sentences, front-loading the purpose immediately. Every word contributes meaning without redundancy. Ideal length for a straightforward tool.
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?
Given the complexity (nested object parameter, creation tool, no output schema), the description is too sparse. It does not explain the return value (e.g., created theme ID), error conditions, or uniqueness constraints on name. Missing critical context for effective use.
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 50% (name undocumented, style partially documented). The description adds value for 'style' by listing example fields (fgColor, bgColor, dotType, cornerSquareType), which the schema's description does not include. No additional clarification for 'name'. This partial compensation results in a mid-range score.
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 clearly states the tool saves a reusable style theme, with specific verb ('Save') and resource ('reusable style theme'). It distinguishes from siblings like delete_theme and list_themes by focusing on creation. However, it could more explicitly differentiate from create_dynamic_qr, which also creates something but is different.
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?
The description notes the required API key and hints at the style object structure, giving some context on when to use the tool (saving a reusable theme). However, it lacks explicit guidance on when not to use it versus alternatives like create_dynamic_qr or generate_qr, and no prerequisites beyond the API key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_dynamic_qrAInspectPermanently delete a dynamic QR code. The short link stops working. Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The dynamic code id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully conveys behavior: permanent deletion, short link stops working, and API key requirement. This is sufficient for a simple delete operation, though it could mention associated data impact.
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 sentences with no extraneous content. The purpose is front-loaded, and every word serves a clear function.
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 tool with one parameter and no output schema, the description fully covers purpose, behavioral effect, and prerequisite. Nothing additional is needed.
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 100% with a single 'id' parameter described as 'The dynamic code id.' The description adds no further meaning beyond the schema, meeting the baseline for high coverage.
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 explicitly states 'Permanently delete a dynamic QR code' with a clear verb and resource. It distinguishes this tool from siblings like create, update, or list operations.
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?
The description indicates when to use the tool (to delete a QR code) and a prerequisite ('Requires an OpenQR API key'). It does not explicitly state when not to use or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_folderBInspectDelete a folder (its codes are un-filed, not deleted). Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that codes are un-filed, not deleted, which is a non-obvious behavior. However, without annotations, it does not mention whether deletion is reversible or other side effects.
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 concise sentences covering action and requirement, with no unnecessary words.
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?
Covers purpose and effect adequately for a simple tool, but lacks description of return value or confirmation, which would be helpful given no output schema.
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?
No parameter-level information added; the single parameter 'id' is not described beyond what the schema provides. Description does not clarify its meaning or format.
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?
Description clearly states it deletes a folder and explains the effect on its codes, distinguishing it from other delete tools like delete_dynamic_qr and delete_theme.
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?
Implicitly guides usage by naming the resource (folder) and prerequisite (OpenQR API key), but does not explicitly state when to use versus alternatives or provide when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_themeAInspectDelete a saved theme. Codes already styled with it keep their look. Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It does reveal a key non-destructive side effect ('Codes already styled with it keep their look') and the API key requirement. However, it does not mention other important traits like idempotency, error behavior for invalid IDs, or whether the deletion is permanent.
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?
The description is extremely concise with two short sentences. The main action is front-loaded, and every sentence adds value. There is no wasted text.
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?
Given the tool's simplicity (one parameter, no output schema), the description covers the main action and an important behavioral effect. It also notes the API key requirement. However, it could mention what happens if the theme does not exist or if the operation fails.
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?
The input schema has one required parameter 'id' with 0% description coverage. The tool description does not clarify what 'id' represents (e.g., theme ID, string format, or how to obtain it). This leaves the agent without necessary context to fill the parameter correctly.
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 starts with a clear verb+resource phrase 'Delete a saved theme', which directly states the action and object. It also distinguishes from sibling tools like delete_dynamic_qr or delete_folder by specifying 'theme'. The additional note about codes keeping their look adds specificity.
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?
The description mentions the requirement of an OpenQR API key, but does not provide any guidance on when to use this tool versus alternatives (e.g., when to delete a theme vs. update it). Usage context is implied by the tool name but not explicitly addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_qrAInspectGenerate a static QR code from any text/URL. Returns a PNG image (or SVG markup). Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The content to encode (URL or text). | |
| size | No | Pixel size, 64–2048 (default 512). | |
| theme | No | A saved theme id or name. Applies the theme's colours (SVG); full styling applies to dynamic codes. | |
| format | No | Output format (default png). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the API key requirement and output format, but with no annotations, it does not disclose whether the operation is destructive or has side effects, which is important for an agent.
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 sentences, no unnecessary words. It front-loads the purpose and follows with output and requirement details efficiently.
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 tool with 4 parameters and no output schema, the description covers the essentials: what it does, output format, and API key. However, it could provide more context about tool selection among siblings.
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?
The input schema already describes all parameters (100% coverage). The description adds no additional meaning beyond restating the output format and content type, so it meets the baseline without extra value.
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 clearly states it generates a static QR code from any text/URL, distinguishing it from sibling tools focused on dynamic QR codes, themes, and folders.
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?
While the description implies use for static QR codes, it lacks explicit guidance on when to use this tool versus alternatives like create_dynamic_qr, and provides no exclusions or context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dynamic_qrAInspectGet the full details of one of your QR codes by id: destination, short link, label, type, tags, folder, status and created date. Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The code id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the API key requirement and lists the return fields. However, it does not explicitly state that the operation is read-only (though 'Get' implies it) or discuss error behavior.
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?
The description is concise: a single sentence with a clear action, a list of returned fields, and an auth note. It is front-loaded with the core purpose and contains no wasted words.
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 get tool with no output schema, the description adequately covers the purpose, the fields returned, and the required authentication. It lacks an explicit read-only declaration, but the verb 'Get' communicates this implicitly.
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 100% for the 'id' parameter, so the schema already documents it. The description only repeats 'by id' without adding additional meaning, thus remaining at the baseline of 3.
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?
Description clearly states the verb 'Get' and the resource ('one of your QR codes'), specifies it is by id, and lists the fields returned. This distinguishes it from sibling tools like list_dynamic_qr which lists multiple codes.
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?
The description implies use for fetching a single QR code by id, but it does not explicitly contrast this with list_dynamic_qr or mention when not to use it. There is no explicit alternative named or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scansBInspectGet scan statistics for a dynamic QR code. Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The dynamic code id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only states the purpose and requirement but does not disclose behavioral details such as error responses, rate limits, or authentication behavior.
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?
Single sentence with a clear verb-first structure. The requirement is appended efficiently, but could be integrated. No extraneous information.
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?
Simple tool with one parameter and no output schema, yet the description does not specify what 'scan statistics' includes (e.g., counts, dates), leaving agents uncertain about the return value.
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 100% with a description for the single parameter 'id'. The description adds no further meaning beyond the schema, meeting baseline expectations.
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?
Description clearly states the verb 'Get' and resource 'scan statistics for a dynamic QR code', which is specific and distinguishes from sibling tools like list_dynamic_qr (listing codes) or create_dynamic_qr.
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?
Mentions the requirement of an OpenQR API key but does not provide explicit guidance on when to use this tool versus alternatives, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subdomainAInspectShow the branded subdomain on this account ({name}.oqr.to). Reports whether it is currently suspended — a suspended subdomain redirects to the plain short link instead of serving, which happens when a Pro plan lapses. Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does an excellent job. It explains the suspended subdomain behavior, its cause (Pro plan lapse), and the authentication requirement. This goes beyond a simple read and provides meaningful context.
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?
Three concise sentences, each adding value. Front-loaded with the main purpose, followed by suspension details and auth requirement. No wasted words.
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 getter with zero parameters and no output schema, the description covers the core functionality, the suspension nuance, and prerequisites. It is complete for the tool's complexity.
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?
There are no parameters, and schema coverage is trivially 100%. The description doesn't need to explain parameters. Baseline for 0 params is 4, which is appropriate here.
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?
Clearly states it shows the branded subdomain for the account and reports suspension status. The verb 'show' and resource 'subdomain' distinguish it from siblings like set_subdomain and clear_subdomain, which imply modification.
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?
Usage is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives like set_subdomain or clear_subdomain. The suspension reporting hints at a use case, but no when-not or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_dynamic_qrAInspectList your dynamic (editable) QR codes — id, short URL, destination, label and status. Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max codes to return, 1–500 (default 200). |
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 discloses the action (list) and returned fields, but does not mention any behavioral traits like pagination behavior, rate limits, or error handling. It is straightforward with no contradictions.
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?
The description is extremely concise: two sentences with no filler. The first sentence states the function and returned fields, the second adds the requirement. 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 list tool with one optional parameter and no output schema, the description is fairly complete. It specifies what is listed, the fields, and a prerequisite. Minor missing details like pagination are covered by the schema. Adequate for successful 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?
The single parameter 'limit' is fully described in the input schema (coverage 100%). The description adds no extra meaning to the parameter beyond what the schema provides. Baseline 3 applies.
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 clearly states the verb 'list', the resource 'dynamic QR codes', and enumerates the fields returned (id, short URL, destination, label, status). This distinguishes it from sibling tools like create_dynamic_qr or delete_dynamic_qr.
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?
The description mentions the prerequisite 'Requires an OpenQR API key', but does not explicitly specify when to use this tool versus alternatives. However, the name and context make the purpose clear enough for an agent to select it for listing actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_foldersAInspectList your folders (id and name). Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 discloses the API key requirement and implies read-only behavior through 'List'. No contradictions, but could explicitly state it is read-only.
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?
The description is a single, concise sentence that front-loads the purpose and adds a necessary requirement. No wasted words.
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?
Given the simplicity of the tool (no parameters, no output schema), the description is largely complete. It could be improved by specifying the output format (e.g., array of objects), but the core functionality is conveyed.
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?
There are no parameters, and schema description coverage is 100%. The description adds no parameter information beyond what is already clear from the schema, which is acceptable.
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 clearly states the action ('List'), the resource ('folders'), and the returned fields (id and name). It is specific and distinguishes from sibling tools like create_folder or delete_folder.
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 guidance on when to use this tool versus alternatives like list_dynamic_qr. The only mention is the API key requirement, which is a prerequisite rather than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_themesAInspectList your saved style themes (id, name) — apply one by passing its id or name as theme to generate/create/update tools. Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description covers authentication but omits details on read-only nature, rate limits, or any side effects, which would be useful for a list tool.
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 sentences efficiently convey purpose, usage, and requirement with no redundancy, front-loading the key information.
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?
Given the simplicity (no params, no output schema), the description fully covers what the tool returns and its role in the workflow, leaving no gaps.
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?
With zero parameters and 100% schema description coverage, the description appropriately does not add parameter details, meeting the baseline for no-param tools.
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 clearly states the tool lists saved style themes with id and name, and explains its use in other tools, distinguishing it from siblings like list_dynamic_qr.
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?
It mentions the prerequisite of an OpenQR API key and the context of applying themes to other tools, but does not explicitly exclude alternative use cases or compare with create_theme.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_subdomainAInspectClaim or change the branded subdomain so codes also resolve at {name}.oqr.to. Pro only. Codes keep working on the plain short link either way, so changing this never breaks anything already printed. Requires an OpenQR API key.
| Name | Required | Description | Default |
|---|---|---|---|
| subdomain | Yes | 3–32 letters, numbers or hyphens, e.g. "acme". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses important traits: the operation is safe ('never breaks anything'), requires Pro and an API key, and codes continue to work on the plain short link. This is strong behavioral disclosure for a mutation tool.
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?
The description is concise: three sentences, each adding distinct value (purpose, prerequisites, safety guarantee). It is front-loaded with the primary action and contains no filler.
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 single-parameter mutation tool, the description covers the essential context: what it does, required conditions, and the non-breaking guarantee. No output schema exists, but the tool's simplicity means the description is sufficient.
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?
The schema description covers 100% of the parameter meaning ('3–32 letters, numbers or hyphens, e.g. "acme"'). The tool description adds no extra semantic information beyond what the schema already provides, so the baseline 3 applies.
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 clearly states the action with specific verbs ('Claim or change') and a specific resource ('branded subdomain'). It also explains the result ('codes also resolve at {name}.oqr.to'), which distinguishes it from sibling tools like clear_subdomain and get_subdomain.
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?
The description provides clear usage context by stating prerequisites ('Pro only', 'Requires an OpenQR API key') and the effect on existing codes. It doesn't explicitly mention alternatives, but the sibling names make the distinctions obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_dynamic_qrAInspectEdit 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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The dynamic code id. | |
| pin | No | Pro: require a 4-digit PIN before the code redirects. Exactly 4 digits. Pass null to remove all protection. | |
| slug | No | Custom short-link back-half (oqr.to/<slug>): 3–48 letters, numbers or hyphens. | |
| tags | No | Replace the code's tags (max 10). | |
| label | No | New label. | |
| theme | No | A saved theme id or name to restyle the code with. | |
| status | No | Pause the code (it stops resolving — scanners see an inactive page) or reactivate it. Free plan allows up to 3 active codes. | |
| password | No | Pro: require this password before the code redirects (min 4 characters). Pass null to remove all protection. | |
| folder_id | No | Move into a folder id, or null to un-file. | |
| lock_hint | No | Optional hint shown on the unlock page, e.g. "Ask at the bar". Max 60 characters. | |
| destination | No | New http(s) URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses mutation ('Edit'), partial update behavior ('Pass only the fields you want to change'), and auth requirement ('Requires an OpenQR API key'). However, it does not mention side effects, reversibility, or what happens to unspecified fields beyond the partial-update implication.
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 sentences, front-loaded with the main action. Every word serves a purpose, and the 'Pass only...' instruction is a high-value usage tip. No fluff or repetition.
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?
Given the tool's complexity (11 params) and rich schema, the description provides sufficient context for selection and invocation: it states the update verb, key fields, partial-update behavior, and auth required. It could add a mention of how to obtain the id, but the schema covers that.
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 100%, so the schema already documents all 11 parameters. The description restates a few fields (destination, label, slug, tags, folder) but adds no new semantic meaning beyond what's in the schema, warranting the baseline score.
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 clearly states the tool's function: 'Edit a dynamic QR code' and lists specific mutable fields (destination, label, slug, tags, folder). This distinguishes it from sibling tools like create_dynamic_qr, get_dynamic_qr, and delete_dynamic_qr, which have different verbs and resources.
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 explicit usage guidance: 'Pass only the fields you want to change' indicates partial update semantics, and 'Requires an OpenQR API key' sets a prerequisite. It does not explicitly name alternatives or exclusions, but the edit context is clear given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
