How do I use TheQRCode?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@TheQRCode generate a QR code for https://theqrcode.io/pricing" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

TheQRCode

by zwznco

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

TheQRCode.io MCP Server

Listed on mcpservers.org TheQRCode MCP server on Glama

Generate QR codes — and read their scan analytics — from Claude, Cursor, or any MCP client.

Remote HTTP server. Nothing to install. No npm, no Docker, no Python. Point your client at one URL and ask.

https://mcp.theqrcode.io/mcp

Listed in the official MCP Registry as io.theqrcode/qr-code-generator.

Setup

Claude Desktop

Settings → Developer → Edit Config:

{
  "mcpServers": {
    "theqrcode": {
      "url": "https://mcp.theqrcode.io/mcp"
    }
  }
}

Cursor

~/.cursor/mcp.json:

{
  "mcpServers": {
    "theqrcode": {
      "url": "https://mcp.theqrcode.io/mcp"
    }
  }
}

With an API key (unlocks the analytics tools)

{
  "mcpServers": {
    "theqrcode": {
      "url": "https://mcp.theqrcode.io/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Any client supporting the MCP spec over streamable HTTP works. Restart the client after editing config, then just ask: "Generate a QR code for https://example.com".

Related MCP server: QR Forge MCP server

Tools

Three tools. All three are advertised to every session — including anonymous ones, so directory crawlers see the real surface — but the two account tools refuse at call time without a key.

`generate_qr_code` — free, no key

Param	Type	Required	Notes
`type`	`url` \| `wifi` \| `contact` \| `text` \| `email`	yes	all five free, no key
`content`	string	yes	the data to encode
`name`	string	no	display name when saving to an account
`size`	int 64–1024	no	default 256
`darkColor`	`#RRGGBB`	no	default `#000000`
`lightColor`	`#RRGGBB`	no	default `#FFFFFF`
`dotStyle`	`square` \| `dots` \| `rounded` \| `extra-rounded` \| `classy` \| `classy-rounded`	no	module shape
`cornerStyle`	`square` \| `dot` \| `extra-rounded`	no	the three corner squares
`frameStyle`	`square` \| `rounded` \| `circle` \| `dashed`	no	`square` means no frame
`caption`	string ≤60	no	text under the code; implies a frame
`format`	`png` \| `svg` \| `pdf`	no	default `png`; svg/pdf need a key

Returns a hosted image URL plus a base64 data URL for inline display. svg and pdf come back as a data URL in the text response rather than an image block, since a PDF is not one and many clients will not draw an SVG one.

Every design option is free, on every plan and with no key at all — colour, size, dot and corner styling, frames and captions, with no watermark on any output. What the paid plans sell is dynamic codes, analytics, stored-code volume and the managed API. Logo embedding is free too but is not a parameter here: it needs a base64 data URL, which is a poor fit for a tool call.

format: "svg" | "pdf" is the one asymmetry, and it is a cost control rather than a paywall: vector and PDF are the most expensive render path, so they are metered per key instead of per IP. Both are free in the dashboard and in the no-signup generator on theqrcode.io, on every plan.

Anonymous → the public keyless API, 100 requests/hour per IP. The hosted link is a 24-hour preview; download the image rather than bookmarking the URL. The QR code itself never expires — it is the preview hosting that is temporary.

Authenticated → the v1 API. The code is saved to your account permanently, rate limited by key rather than IP, and format: "svg" | "pdf" becomes available.

`list_qr_codes` — Developer plan

Lists codes saved to your account. page, limit (1–100), type filter.

`get_analytics` — Developer plan

Scan analytics, account-wide or for one qrCodeId. timeRange: 1h, 1d, 7d, 30d (default), 90d, 1y.

Returns total and unique scans, time, approximate location (country/city derived from IP — regional, not GPS), device and OS, and campaign. Static QR codes cannot be tracked; analytics require a dynamic code.

Plans

	Anonymous	Developer ($19/mo)	Pro ($29/mo)
`generate_qr_code`	✅ all 5 types, full design	✅ + svg/pdf output	✅ + svg/pdf output
Codes saved to account	❌ 24h preview link	✅ permanent	✅ permanent
`list_qr_codes`	❌	✅	❌
`get_analytics`	❌	✅	❌
MCP rate limit	100/hr per IP	2,000/hr per key	500/hr per key

MCP calls also count toward the key's 5,000/hr REST API limit; the MCP limit is a cap within it.

API keys: https://theqrcode.io/pricing

Running it yourself

The hosted server at mcp.theqrcode.io is the supported path — you do not need to run this. But it is a plain Express app if you want to:

npm install
npm run build
npm run start:http # HTTP server on $PORT (or: npm run dev)
npm start          # one session over stdio, for a local client
npm test

Over stdio, set THEQRCODE_API_KEY to unlock the account tools; without it you get the keyless set.

Env	Default	Purpose
`QR_API_BASE`	`https://theqrcode.io`	REST API this server wraps
`PORT`	`3001`	listen port (HTTP mode)
`THEQRCODE_API_KEY`	—	API key for stdio mode (HTTP takes it per request as a Bearer token)

Routes: POST|GET|DELETE /mcp (stateless — a fresh server and transport per request), GET /health.

Docker:

docker build -t theqrcode-mcp .
docker run -p 3001:3000 -e PORT=3000 theqrcode-mcp

What it wraps

TheQRCode.io is a QR code generation and analytics platform: static and dynamic QR codes for URLs, WiFi, vCard contacts, text and email, with scan analytics by time, device and approximate location. Static codes never expire, printed codes are never switched off to force an upgrade, and the design of a code is never billed for.

This server is one of three ways in — the others are a keyless REST API and OpenAI function calling.

Site — https://theqrcode.io
REST API — https://theqrcode.io/qr-code-api
OpenAPI spec — https://theqrcode.io/api/public/qr-codes/openapi.json
Agent guide — https://theqrcode.io/llms-full.txt

License

MIT — see LICENSE.

Available Tools

3 tools

generate_qr_codeAInspect

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
`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.

TDQS

A4.3/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_analyticsBInspect

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'.

TDQS

B3.4/5.0

Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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_codesAInspect

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
`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.

TDQS

A4.2/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv1.5.2Oct 13, 2026
- First observedgenerate_qr_code
- First observedget_analytics
- First observedlist_qr_codes

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-10-16 15:15 across 3 tools

Disambiguation5/5

Each tool targets a clearly distinct operation: generating a QR code, listing saved QR codes, and retrieving scan analytics. There is no overlap or plausible confusion between them, and descriptions reinforce the boundaries.

Naming Consistency5/5

All three names follow a clean verb_noun snake_case pattern (generate_qr_code, list_qr_codes, get_analytics). Verbs are distinct and appropriate to the action (generate vs list vs get), with no mixed conventions.

Tool Count4/5

Three tools is on the lean side but each earns its place for a focused QR generation/analytics service. It sits just below the comfortable 5-10 range but is not thin or bloated.

Completeness3/5

Core workflows (generate, list, analytics) are covered, but the saved-QR-code lifecycle is incomplete: there is no delete, update, or single-item get for saved codes. Agents managing existing QR codes will hit dead ends.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Related MCP Connectors

QRSalt
io.github.QRSalt
Make, re-point and track QR codes and short links, and read QR images, from your AI assistant.
Marketing Image & Video Processing
1
https://app.qrsalt.com/api/mcp
QR Rápido
site.qrrapido
Generate QR codes for URLs, PIX, Wi-Fi, vCards, WhatsApp and more. For AI agents.
Developer Tools Communication Payments & Billing
26,314
https://qrrapido.site/api/mcp
GhostQR
io.github.Ajshawit
Create and update dynamic QR codes, change their destinations, and read scan analytics.
Marketing
1
https://ghqr.au/api/mcp
QRcodly
de.qrcodly
Create, manage, and share QR codes and short URLs
App Automation Marketing
216
https://mcp.qrcodly.de/mcp

Related MCP Servers

QR for Agent
Marketing App Automation
benswel
A
license
A
quality
D
maintenance
Dynamic QR code platform for AI agents. Create, customize, and track QR codes without regenerating images. 37 tools covering 11 QR types (URL, vCard, WiFi, event…).
Updated 5 months ago (2026-06-09 08:25 UTC)
37
3
MIT
QR Forge MCP server
Marketing Communication
jkolarov
A
license
A
quality
D
maintenance
Enables AI agents to create and manage trackable QR codes (URLs, Wi-Fi, WhatsApp, etc.) via the QR Forge API.
Updated 5 months ago (2026-06-07 20:13 UTC)
25
MIT
sharecut-mcp
Marketing
LucaRSdeCo
A
license
Not graded
quality
C
maintenance
Enables generating QR codes from URLs or text without an API key, and creating trackable short links whose printed QR codes can be re-pointed after printing.
Updated 19 days ago (2026-10-14 16:04 UTC)
48 npm
MIT
OpenQRofficial
Marketing
open-qr
A
license
Not graded
quality
A
maintenance
Generate QR codes and create, edit and track dynamic (editable) QR codes with scan analytics, folders, style themes and branded subdomain management. Free REST API with an OpenAPI spec alongside; every tool takes a free API key.
Updated 2 months ago (2026-09-15 20:29 UTC)
12
AGPL 3.0

TheQRCode.io MCP Server

Setup

Claude Desktop

Cursor

With an API key (unlocks the analytics tools)

Tools

generate_qr_code — free, no key

list_qr_codes — Developer plan

get_analytics — Developer plan

Plans

Running it yourself

What it wraps

License

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

QR for Agent

QR Forge MCP server

sharecut-mcp

OpenQRofficial

`generate_qr_code` — free, no key

`list_qr_codes` — Developer plan

`get_analytics` — Developer plan