This has been replaced by https://glama.ai/mcp/connectors/uk.openqr/qr
Generate QR codes and create, edit and track dynamic (editable) QR codes with scan analytics, over a hosted MCP server plus a free REST API. Free, no watermark, no expiry. Every tool takes a free API key from https://openqr.uk/api.
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, 96–2048 (default 512). | |
| theme | No | A saved theme id or name. Applies the theme's colours; 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns PNG or SVG and requires an OpenQR API key, which are useful behavioral details. However, it does not mention any side effects, error conditions, rate limits, or whether the operation is stateless. For a simple generation tool, this is decent but not exhaustive.
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 two sentences long, front-loaded with the core purpose, and includes key output and authentication details without any fluff. Every word adds value, making it highly concise and well-structured.
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?
The tool is simple (4 params, 1 required) and the description covers purpose, output format, and authentication requirement. It lacks explicit mention of error handling or dynamic vs static trade-offs, but given the schema richness and simplicity, it is adequately complete. No output schema exists, but the output types are stated in the description.
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 parameters thoroughly. The description adds minimal extra meaning beyond clarifying 'any text/URL' for data and confirming output formats. This aligns with the baseline of 3 when schema handles parameter 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?
The description clearly states 'Generate a static QR code' – a specific verb and resource. It distinguishes from siblings like create_dynamic_qr by using 'static', and mentions input (text/URL) and output (PNG/SVG). This is explicit and 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?
The description implies usage for static QR codes but does not explicitly mention when to avoid using it or provide alternative tools. It notes the API key requirement as a prerequisite but offers no guidance on choosing between static and dynamic options. The phrase 'static' hints at the distinction but no explicit 'when-not' or alternative reference is given.
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. | |
| pause_until | No | 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. | |
| ios_destination | No | 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. | |
| android_destination | No | App links: Android scanners follow this http(s) URL instead of destination (e.g. the Google Play page). Pass null to clear. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful behavioral context: 'Pass only the fields you want to change' communicates partial-update semantics, and 'Requires an OpenQR API key' states an auth prerequisite. However, it does not disclose side effects, validation limits, or what happens to unspecified fields, though the update semantics partly mitigates this.
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 two tight sentences with no filler. It front-loads the core action, gives representative editable fields, explains partial-update behavior, and adds the API key requirement. Every sentence 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?
Given 14 parameters, no output schema, and no annotations, the description is adequate but not deeply complete. It covers the high-level purpose, auth requirement, and partial-update semantics, while the schema covers parameter details. It does not mention the return value, error conditions, or effects beyond the edit, which would be useful for a high-complexity tool.
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 baseline is 3 and the schema already documents all 14 parameters thoroughly. The description names a few parameters (destination, label, slug, tags, folder) but adds no parameter-level detail beyond what the schema provides. The useful operational hint about passing only desired fields is a general partial-update semantic, not a parameter-specific clarification.
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 edits a dynamic QR code and lists the main editable properties (destination, label, slug, tags, folder). The verb 'Edit' plus the resource 'dynamic QR code' makes it easy to distinguish from create_dynamic_qr, delete_dynamic_qr, and list_dynamic_qr. The field list is representative even if not exhaustive, and the partial-update sentence reinforces the operation.
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 context: use this to modify an existing dynamic QR code by passing only the fields to change. It does not explicitly state when not to use it or name alternatives, but the action is unambiguous against siblings like create_dynamic_qr and delete_dynamic_qr. The API key requirement also gives a necessary precondition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
qart.uk MCP server: resolve scanned codes, browse the free pool, and buy QR artwork.
Generate static QR codes (URL, WiFi, vCard, pixel art) and decode QR images. Codes never expire.
Dynamic, editable QR codes + short links with scan analytics and branded QR rendering.
