QrVerloz
Server Details
QR codes active 90 days, claimable forever. Request an API key in chat to retarget and track scans.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.3/5 across 8 of 8 tools scored.
Each tool has a clearly distinct purpose: creating, deleting, retrieving, listing, updating target URL, getting scan counts, account info, and requesting an API key. No overlap or ambiguity.
All tools follow a consistent verb_noun pattern in lower_snake_case (e.g., create_qr_code, delete_qr_code, update_qr_target). No mixing of conventions.
8 tools cover the essential operations for a QR code service (CRUD, analytics, account management, API key request) without being excessive or insufficient.
Core lifecycle is well-covered: create, read, update (target), delete, list, and scans. Missing potential features like editing QR code title/description or bulk operations, but not essential for the main use case.
Available Tools
8 toolscreate_qr_codeAInspect
Create a new QR code. Authenticated users (API key required) get a permanent short URL that can be retargeted at any time without reprinting the physical QR image — limits are set by the account plan. Anonymous users receive a one-time data URI image that is not stored and cannot be updated. On success the result is a pre-formatted markdown table — display it exactly as received, do not reformat or summarise.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | A human-readable label for the QR code | |
| target_url | Yes | Destination URL — must start with https:// or http:// |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully informs about behavioral differences: authenticated users get a permanent, retargetable short URL with account limits, while anonymous users receive a one-time data URI. It also explicitly states the output format (markdown table) and instructs not to reformat.
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 paragraph that conveys all necessary information without excess. It is well-structured but could be slightly improved by separating the output instruction into its own sentence for clarity.
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 annotations or output schema, the description covers key aspects: authentication modes, storage behavior, account limits, and output format. It lacks details on error handling or validation beyond what the schema provides, but is largely complete for a create 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?
The input schema has 100% coverage with descriptions for both parameters (title and target_url). The description does not add further meaning beyond the schema, 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 a new QR code' and distinguishes between authenticated and anonymous users, which sets it apart from sibling tools like get_qr_code and delete_qr_code. The verb+resource is specific 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 provides clear guidance on using the tool with or without authentication, explaining differences in storage and retargeting. However, it does not explicitly mention when not to use this tool or compare to alternatives like update_qr_target.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_qr_codeAInspect
Permanently delete a QR code and its scan history. This action cannot be undone. To prevent accidental or injected deletions, you MUST supply confirm_title — the exact title of the code as returned by get_qr_code or list_qr_codes. If the title does not match the stored record, the deletion is refused. Always call get_qr_code or list_qr_codes first to retrieve the exact title before calling this tool. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| qr_code_id | No | Internal UUID from create_qr_code or list_qr_codes | |
| short_code | No | Short code from the redirect URL (e.g. "abc123") | |
| confirm_title | Yes | The exact title of the QR code to delete — must match the stored title character-for-character. This prevents blind or injected deletions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: permanent deletion, irreversibility, safety mechanism (confirm_title matching), and need for prior title retrieval. 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?
Four sentences, front-loaded with the core action. Every sentence is informative without redundancy. 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?
Covers permanence, required parameter, prerequisites, and authentication. Lacks clarification on whether at least one of qr_code_id or short_code is needed for identification, which is a minor gap.
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 covers 100% of parameters, so baseline is 3. The description adds value by explaining confirm_title's safety purpose and instructing to retrieve it first, but does not elaborate on qr_code_id or short_code beyond schema.
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 (permanently delete) and the resource (QR code and its scan history). It distinguishes from sibling tools (create, get, list, update) by being the only deletion tool and emphasizing irreversibility.
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?
Explicitly instructs to first retrieve the exact title via get_qr_code or list_qr_codes, mandates confirm_title to prevent accidental/injected deletions, and notes authentication requirement. Provides clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_account_infoAInspect
Get your account details: current plan, QR code usage, and which features are available. Use this before create_qr_code to check remaining capacity, or to confirm which features are active on your plan. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Absent annotations, the description carries full burden. It discloses authentication requirement and return fields but omits details like data freshness, caching, or side effects. 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?
Two sentences with no fluff. Each sentence serves a purpose: defining the tool and providing usage guidance. Perfectly succinct.
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 parameterless info retrieval tool without an output schema, the description appropriately names the returned fields. However, it could mention if the data is real-time or cached, but overall it's complete enough for its simplicity.
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 parameters exist, so schema coverage is 100%. The description adds value by specifying what information is returned (plan, usage, features), which goes beyond the empty schema.
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 retrieves account details including plan, QR code usage, and feature availability. It distinguishes from sibling tools like get_qr_code by focusing on account-level information.
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?
Explicitly advises using this before create_qr_code to check remaining capacity and to confirm active features. Also notes authentication requirement, providing clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_qr_codeAInspect
Look up a single QR code by its internal ID or short code. Returns a pre-formatted markdown table with fields: Title, ID, Short Code, Short URL, Destination, Status, Created, QR Code Link. Display the table exactly as received — do not reformat or summarise. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| qr_code_id | No | Internal UUID from create_qr_code or list_qr_codes | |
| short_code | No | Short code from the redirect URL (e.g. "abc123") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It adds useful behavioral context: returns a pre-formatted markdown table and instructs not to reformat. However, it lacks disclosure of error handling (e.g., what if QR code not found) and other traits like rate limits.
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 purpose, no fluff. Every sentence adds value.
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?
No output schema, but the description lists all returned fields. It mentions authentication. However, it could be more complete by specifying behavior on not found or error responses.
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%, with both parameters having clear descriptions. The description reinforces that both ID and short code are valid lookup keys, but does not add significant meaning beyond the schema.
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 looks up a single QR code by its internal ID or short code, and returns a markdown table. It distinguishes from sibling tools like list_qr_codes (which lists multiple) and create_qr_code (which creates).
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 when you have an ID or short code and want details, and mentions authentication. However, it does not explicitly state when not to use this tool or mention alternatives like list_qr_codes for multiple records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_qr_scansAInspect
Get the total lifetime scan count for a QR code. Returns a pre-formatted markdown table with fields: Title, ID, Short Code, Short URL, Destination, Status, Created, QR Code Link, Total Scans. Display the table exactly as received — do not reformat or summarise. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| qr_code_id | Yes | Internal UUID of the QR code |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the return format (markdown table) and authentication requirement. For a simple read operation, this is adequate, though it could mention error handling or null results.
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 purpose, no unnecessary words. Every sentence adds value: purpose, return format, do-not-reformat instruction, and authentication 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?
For a simple one-parameter tool with no output schema, the description covers input, output format, and auth requirements. Lacks error handling details, but overall sufficient for the 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?
Schema coverage is 100% and the description adds no additional meaning to the single parameter 'qr_code_id'. The schema already describes it as 'Internal UUID of the QR code', so 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 'Get', the resource 'QR code', and the specific data 'total lifetime scan count'. It also mentions the return format, distinguishing it from siblings like list_qr_codes or get_qr_code.
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 clear context: requires authentication and returns a markdown table. It instructs the agent to display the table exactly as received. While it doesn't explicitly state when not to use, the purpose is self-explanatory and siblings offer alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_qr_codesAInspect
List all QR codes in your account. Returns one pre-formatted markdown table per QR code with fields: Title, ID, Short Code, Short URL, Destination, Status, Created, QR Code Link. Display each table exactly as received — do not reformat or summarise. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| limit | No | Items per page, max 20 (default: 20) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions authentication and the markdown table return format, but fails to disclose pagination behavior (page/limit params) and that it may not return all QR codes in one call. This omission affects transparency.
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 three sentences, front-loaded with purpose, then return format, then usage instruction. Every sentence adds value without redundancy. It is 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 description explains the return format adequately but omits important context like pagination behavior, ordering, and how to retrieve all results. Given no output schema, more detail on what the response represents would improve 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?
Input schema coverage is 100% with descriptions for both parameters. The description adds no extra meaning about parameters, such as how pagination works or the meaning of default values. Baseline score 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 'List all QR codes in your account,' specifying a verb and resource. It distinguishes from sibling tools like create, delete, and get single QR code, making the purpose 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 provides clear context but lacks explicit exclusions or when-not to use. It includes a usage instruction about displaying tables exactly, which aids the agent, but no comparison to alternative tools like get_qr_code or get_qr_scans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_api_keyAInspect
Get a free API token — no account or email required. The token gives you up to 5 QR codes that can be updated at any time. IMPORTANT LIFETIME WARNING: the token expires after 90 days, and QR codes are permanently deleted ~90 days after that (~180 days total). To keep codes alive permanently, claim a free account at https://qrverloz.com/claim — this must be done before the token expires. Save the returned token: it is shown only once. Add it to your MCP client config under Authorization: Bearer, then call create_qr_code.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: token expiry at 90 days, QR code deletion after ~180 days, and that the token is shown only once. This allows the agent to understand risks and constraints.
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 relatively long but each sentence adds critical information (purpose, warning, account claim, token handling). Information is front-loaded and well-structured, though slight trimming could improve conciseness.
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 covers token usage and lifetime. It also ties into the sibling tools (create_qr_code). It lacks technical details like response format but compensates with practical instructions for the MCP client.
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 no parameters, placing the burden on the description. The description explains that no account or email is needed and what the token provides. This adds sufficient meaning beyond the empty schema.
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 identifies the tool's purpose: obtaining a free API token without requiring an account. It specifies the token grants up to 5 QR codes and includes a critical lifetime warning. This verb+resource pairing effectively distinguishes it from sibling tools.
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 explicit steps after token retrieval (adding to MCP config, calling create_qr_code) and mentions claiming a free account for permanent codes. While it doesn't list when-not-to-use or directly compare to get_account_info, the context is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_qr_targetAInspect
Change the destination URL of a QR code without touching the printed image. Print once, redirect anywhere — forever. Accepts either the internal qr_code_id or the short_code from the redirect URL. On success the result is a pre-formatted markdown table — display it exactly as received, do not reformat or summarise. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| qr_code_id | No | Internal UUID from create_qr_code or list_qr_codes | |
| short_code | No | Short code from the redirect URL (e.g. "abc123") | |
| target_url | Yes | New destination URL — must start with https:// or http:// |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full transparency burden. It discloses the output format (pre-formatted markdown table) and authentication requirement. It does not explicitly mention side effects or validation behavior, but the key behavioral traits are covered.
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 front-loaded sentences: purpose, benefit, and input/output details. No filler words. 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?
Complete for a simple update tool. With no output schema, the description explains the return format. Input alternatives are clear, and authentication is stated. No gaps remain.
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 all 3 parameters with descriptions. The description adds value by clarifying that qr_code_id and short_code are alternative identifiers, reducing ambiguity. Schema coverage is 100%, so a score above 3 is justified.
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 ('Change the destination URL of a QR code') and the resource ('QR code'), with a distinctive benefit ('without touching the printed image'). This effectively differentiates from sibling tools like create, delete, and get.
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 explains the two alternative parameters (qr_code_id or short_code) and that authentication is required. However, it does not explicitly state when NOT to use this tool or suggest alternatives for other use cases.
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.
Discussions
No comments yet. Be the first to start the discussion!