Free styled QR codes, no key: URL, WiFi, contact, text, email. API key adds saved codes + analytics.
Scored across 3 tools
Each tool targets a distinct action-resource pair: generation, analytics retrieval, and listing. There is no meaningful overlap, and the descriptions clearly delineate when each applies (e.g. analytics scoped to the authenticated user's codes, generation for any user).
All three tools follow a consistent snake_case verb_noun pattern: generate_qr_code, get_analytics, list_qr_codes. While 'get_analytics' omits the resource noun 'qr_code', it stays within the same convention and reads naturally alongside the others.
Three tools is within the well-scoped 3-15 range and each earns its place without redundancy. It is on the lean side for a service that also manages saved codes and analytics, leaving little headroom for per-code operations.
The surface covers create (generate_qr_code), list, and analytics, but there is no get-single-code, update, or delete operation for saved codes. Agents can work around this via list plus filtering, but lifecycle coverage on saved resources is notably incomplete.
Generate a QR code image. Use this whenever a user asks to create, make, or generate a QR code for a URL, website, WiFi network, contact card, email, or text. Returns a hosted image URL and a base64 data URL for inline display. Colour, size, dot and corner styling, frames and captions are free on every plan and with no key at all — offer them freely. When authenticated, the QR code is saved to the user's account and svg/pdf output becomes available.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Display name when saving via the authenticated API. If omitted, a name is derived from type and content. | |
| size | No | Output image size in pixels (64–1024). Defaults to 256. | |
| type | Yes | QR code type. Use 'url' for web links, 'wifi' for network credentials (format: WIFI:T:WPA;S:<ssid>;P:<password>;;), 'contact' for vCard data, 'text' for arbitrary strings, 'email' for email addresses. Every type works without a key. | |
| format | No | Output format, returned as a data URL of that type. Defaults to 'png'. svg and pdf REQUIRE an API key: vector and PDF are the most expensive render path, so they sit behind a per-key rate limit rather than a per-IP one. This is a cost control, not a plan feature — both are free in the dashboard and in the browser generator on every plan. | |
| caption | No | Short text rendered under the code, e.g. 'Scan for the menu'. Forces a frame to be drawn, because the text needs a band to sit on. Free on every plan. | |
| content | Yes | The data to encode. Examples: 'https://example.com' for url, 'WIFI:T:WPA;S:MyNetwork;P:secret;;' for wifi, plain text for text type. | |
| dotStyle | No | Shape of the QR modules. Free on every plan, keyless sessions included. | |
| darkColor | No | Hex color for dark QR modules, e.g. '#1a1a1a'. Defaults to '#000000'. | |
| frameStyle | No | Draw a frame around the code. 'square' means no frame. Free on every plan. | |
| lightColor | No | Hex color for the background, e.g. '#ffffff'. Defaults to '#FFFFFF'. | |
| captionFont | No | Typeface for the caption. Defaults to 'inter' (bold sans). 'pacifico' and 'dancing-script' are scripts, 'permanent-marker' is handwritten, 'playfair-display' and 'roboto-slab' are serifs. Ignored without a caption. | |
| cornerStyle | No | Shape of the three large corner squares. Free on every plan. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so richly: it discloses the return values (hosted image URL plus base64 data URL), the authentication effect (saving to the account, enabling svg/pdf), and a critical cost-control caveat that svg/pdf are rate-limited per-key rather than a plan restriction. That is exactly the kind of behavior an agent needs before calling.
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?
It is front-loaded with purpose, then return values, then free-feature guidance, then auth-gated behavior. Every sentence is informative, though it leans heavily on repeated 'free on every plan' emphasis that could be trimmed slightly without loss of meaning.
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 12 parameters but 100% schema coverage, no output schema, and no annotations, the description supplies the missing behavioral context (return format, auth behavior, rate-limit caveat). It is nearly complete, but does not mention validation or error behavior for bad payloads.
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; the schema already documents all 12 parameters, defaults, formats, and constraints in detail. The description adds the useful free/auth distinction for output formats and styling, but does not explain parameter syntax beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Generate a QR code image') and enumerates the supported payload kinds (URL, WiFi, contact card, email, text). It is clearly distinguishable from siblings list_qr_codes and get_analytics, which manage/a… and analyze existing codes rather than produce one.
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 explicitly triggers on user intent ('whenever a user asks to create, make, or generate a QR code'), which is actionable guidance. It does not name the sibling tools or state when not to use this one (e.g. to list or analyze existing codes), so it falls short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get scan analytics for the authenticated user's QR codes. Optionally filter to a specific QR code by ID. Requires an authenticated API key (Developer plan).
| Name | Required | Description | Default |
|---|---|---|---|
| qrCodeId | No | Filter analytics to a specific QR code ID. Omit for account-wide totals. | |
| timeRange | No | Time range for analytics data. Defaults to '30d'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose a real constraint: an authenticated API key on the Developer plan. However, it omits return shape, whether results are paginated, and any rate-limit or freshness behavior, leaving meaningful gaps for a read 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?
Three short sentences, front-loaded with the core purpose and ending with the auth prerequisite. Nothing is padded, though the auth note could have been folded more tightly into the first sentence.
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?
Purpose, filtering, and auth requirements are covered, but with no output schema the description gives no indication of what analytics data is returned (metrics, aggregation grain, shape). For a metrics-returning read tool this is a notable omission.
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 both qrCodeId and timeRange are already fully documented in the schema, including the '30d' default. The description restates the qrCodeId filtering but adds no syntax or semantics beyond the schema, 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?
States a specific verb and resource ('Get scan analytics') and scopes it to 'the authenticated user's QR codes'. This is clearly distinguishable from the sibling tools generate_qr_code and list_qr_codes, though it never names them explicitly.
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 through the optional-filter phrasing, but it never states when to reach for this tool versus the siblings or what conditions warrant a filtered vs. account-wide query. Usage is inferred rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List QR codes saved to the authenticated user's account. Supports pagination and filtering by type. Requires an authenticated API key (Developer plan).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination. Defaults to 1. | |
| type | No | Filter by QR code type. | |
| limit | No | Number of QR codes per page (1–100). Defaults to 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well by disclosing the auth requirement and plan gating (Developer plan) plus pagination and filtering behavior. It doesn't cover rate limits or default ordering, keeping it from a 5.
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 short sentences, front-loading the primary purpose followed by capability and auth prerequisites—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?
Given a simple read-only list tool with full schema coverage and no output schema, the description covers purpose, capabilities, and auth needs. Return format isn't explained, but for a straightforward listing tool this is largely adequate.
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 per-parameter descriptions (page, limit ranges, type enum), so the schema does the heavy lifting. The description restates pagination and type filtering without adding format details, 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?
States a specific verb (List) and resource (QR codes) scoped to the authenticated user's account, clearly distinguishing it from generate_qr_code (creation) and get_analytics (analytics).
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?
Describes the context (account-scoped listing with pagination and filtering by type) and names a prerequisite (API key, Developer plan), though it doesn't explicitly state when to prefer this over get_analytics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_qr_code2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseget_analytics2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falselist_qr_codes3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / page / maximumAdded value: +9007199254740991generate_qr_code1 field changedInput schema / properties / captionFontAdded value: +{
+ "description": "Typeface for the caption. Defaults to 'inter' (bold sans). 'pacifico' and 'dancing-script' are scripts, 'permanent-marker' is handwritten, 'playfair-display' and 'roboto-slab' are serifs. Ignored without a caption.",
+ "enum": [
+ "inter",
+ "oswald",
+ "bebas-neue",
+ "fredoka",
+ "playfair-display",
+ "roboto-slab",
+ "pacifico",
+ "dancing-script",
+ "permanent-marker",
+ "space-mono"
+ ],
+ "type": "string"
+}generate_qr_code6 fields changedInput schema / properties / captionAdded value: +{
+ "description": "Short text rendered under the code, e.g. 'Scan for the menu'. Forces a frame to be drawn, because the text needs a band to sit on. Free on every plan.",
+ "maxLength": 60,
+ "type": "string"
+}Input schema / properties / cornerStyleAdded value: +{
+ "description": "Shape of the three large corner squares. Free on every plan.",
+ "enum": [
+ "square",
+ "dot",
+ "extra-rounded"
+ ],
+ "type": "string"
+}Input schema / properties / dotStyleAdded value: +{
+ "description": "Shape of the QR modules. Free on every plan, keyless sessions included.",
+ "enum": [
+ "square",
+ "dots",
+ "rounded",
+ "extra-rounded",
+ "classy",
+ "classy-rounded"
+ ],
+ "type": "string"
+}Input schema / properties / formatAdded value: +{
+ "description": "Output format, returned as a data URL of that type. Defaults to 'png'. svg and pdf REQUIRE an API key: vector and PDF are the most expensive render path, so they sit behind a per-key rate limit rather than a per-IP one. This is a cost control, not a plan feature — both are free in the dashboard and in the browser generator on every plan.",
+ "enum": [
+ "png",
+ "svg",
+ "pdf"
+ ],
+ "type": "string"
+}Input schema / properties / frameStyleAdded value: +{
+ "description": "Draw a frame around the code. 'square' means no frame. Free on every plan.",
+ "enum": [
+ "square",
+ "rounded",
+ "circle",
+ "dashed"
+ ],
+ "type": "string"
+}Input schema / properties / type / descriptionPrevious value: -"QR code type. Use 'url' for web links, 'wifi' for network credentials (format: WIFI:T:WPA;S:<ssid>;P:<password>;;), 'contact' for vCard data, 'text' for arbitrary strings, 'email' for email addresses. Note: 'email' requires a Bearer token — it cannot be used with the public (unauthenticated) MCP session."New value: +"QR code type. Use 'url' for web links, 'wifi' for network credentials (format: WIFI:T:WPA;S:<ssid>;P:<password>;;), 'contact' for vCard data, 'text' for arbitrary strings, 'email' for email addresses. Every type works without a key."get_analyticslist_qr_codesgenerate_qr_codeFree styled QR code generator API. Create QR codes with custom colors, logos, and frame templates. Supports URL, WiFi, Email, Phone, SMS. No API keys required.
Free static QR codes (PNG or SVG) that never expire, for URLs, WiFi, vCards and text. No account.
Generate static QR codes (URL, WiFi, vCard, pixel art) and decode QR images. Codes never expire.
Generate static QR codes that never expire, as PNG images or SVG. No account or API key needed.
Add one secure layer between your agents and this server.
