用于生成简单二维码的模型上下文协议 (MCP) 服务器。支持自定义二维码样式。
Related MCP server: Enhanced QR Code MCP Server
🎨 支持自定义二维码样式
🛠️易于使用
要通过Smithery自动为 Claude Desktop 安装 QRCode_MCP：
npx -y @smithery/cli install @1595901624/qrcode-mcp --client claude克隆存储库
git clone https://github.com/1595901624/qrcode-mcp.git安装依赖项
pnpm install构建项目
pnpm run build添加到您的 Cline MCP 设置文件
{
"mcpServers": {
"qrcode-mcp": {
"command": "node",
"args": ["path/to/qrcode-mcp/build/index.js"],
"disabled": false,
"autoApprove": []
}
}
}qrcode ：生成二维码图片参数：
text ：二维码中编码的文本（必需）
size ：二维码的大小（可选，默认为256）
darkColor ：暗色模块的颜色（可选，默认为#000000）
lightColor ：灯光模块的颜色（可选，默认为#ffffff）
errorCorrectionLevel ：错误校正级别（可选，默认为 M）
margin ：二维码的边距（可选，默认为 4）
# Install dependencies
npm install
# Build the project
npm run build
# Development with auto-rebuild
npm run watch本项目遵循 MIT 许可证。详情请参阅LICENSE文件。
Generate a QR code image
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The input string to generate qrcode | |
| size | No | The size of qrcode, default is 256 | |
| darkColor | No | The dark color of qrcode, default is #000000 | #000000 |
| lightColor | No | The light color of qrcode, default is #ffffff | #ffffff |
| errorCorrectionLevel | No | The error correction level of qrcode, default is M | M |
| margin | No | The margin of qrcode, default is 4 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Generate a QR code image' implies a creation operation but doesn't disclose behavioral traits like whether this is a read-only generation, if it requires external resources, what happens with invalid inputs, or the format of the returned image. For a tool with 6 parameters and no annotation coverage, this is inadequate.
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, efficient sentence with zero waste. It's appropriately sized for a straightforward tool and front-loads the core purpose without unnecessary elaboration.
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 moderate complexity (6 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It states what the tool does but lacks context about the generated output (e.g., image format, return type), error handling, or performance considerations, leaving gaps for the agent.
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 all parameters well-documented in the schema itself. The description adds no additional parameter information beyond implying 'text' is needed for generation. This meets the baseline of 3 since the schema does the heavy lifting, but doesn't provide extra context like typical text lengths or color format 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?
The description 'Generate a QR code image' clearly states the verb 'Generate' and resource 'QR code image', making the purpose immediately understandable. However, it lacks specific differentiation from potential siblings (though none exist in this context), and doesn't specify output format or medium, keeping it from a perfect score.
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 no guidance on when to use this tool versus alternatives, prerequisites, or typical use cases. With no sibling tools, this is less critical, but still leaves the agent without context about appropriate scenarios for QR code generation.
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.
qrcodeScored across 1 tool
With only one tool, there is no possibility of confusion or overlap between tools. The single tool 'qrcode' has a clear and distinct purpose of generating QR code images, making disambiguation trivial.
Since there is only one tool, naming consistency is inherently perfect. The tool name 'qrcode' follows a simple, descriptive pattern, and there are no other tools to compare it against for inconsistency.
A single tool is too few for most practical server purposes, as it limits functionality and flexibility. While it might suffice for a minimal QR code generator, typical servers benefit from multiple tools to handle related operations, such as decoding or customizing QR codes.
The tool surface is severely incomplete for a QR code domain. It only provides generation, missing essential operations like decoding QR codes, customizing appearance, or handling different formats, which are common in such tools and could lead to agent failures in broader tasks.
qart.uk MCP server: resolve scanned codes, browse the free pool, and buy QR artwork.
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.
Generate, edit and track dynamic (editable) QR codes with scan analytics. Hosted MCP and REST API.