This MCP server generates highly customizable QR codes from text or URLs in multiple formats with batch processing capabilities.
• Generate QR codes as Data URLs: Create base64-encoded images in PNG, JPEG, or WebP formats • Generate QR codes as SVG: Produce scalable vector graphics for crisp display at any size • Generate QR codes for terminal display: Create QR codes optimized for terminal output with compact format option • Batch processing: Generate up to 10 QR codes simultaneously in a single operation • Advanced customization: Control error correction levels (L, M, Q, H), dimensions (50-2000px), margins (0-10 modules), and custom color schemes with hexadecimal codes • Standardized MCP interface: Compatible with all MCP clients including Claude Desktop and GitHub Copilot • Multiple deployment options: Available via Docker, Podman, or local Node.js installation
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@QR Code MCP Server generate a QR code for https://mywebsite.com with blue color and high error correction"
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.
Un serveur MCP (Model Context Protocol) pour générer des QR codes à partir de texte ou d'URLs en utilisant Node.js et TypeScript.
Génération de QR codes en multiple formats : DataURL (base64), SVG, et affichage terminal
Options de personnalisation avancées : Niveau de correction d'erreur, taille, marge, couleurs
Génération en lot : Traiter plusieurs textes/URLs en une seule commande
Interface MCP standardisée : Compatible avec tous les clients MCP
Support TypeScript complet : Types sûrs et auto-complétion
Related MCP server: QR Code By API Ninjas MCP Server
Prérequis: Docker ou Podman installé sur votre système
# Avec Docker
docker pull antobrugnot/qrcode-mcp-server:latest
# Ou avec Podman (plus sécurisé, rootless)
podman pull antobrugnot/qrcode-mcp-server:latest
# Build local avec Docker
docker build -t qrcode-mcp-server .
# Build local avec Podman
podman build -t qrcode-mcp-server .Prérequis:
Node.js 18.0.0 ou supérieur
npm ou yarn
# Cloner le projet
git clone <votre-repo>
cd qrcode-mcp
# Installer les dépendances
npm install
# Builder le projet
npm run build# Avec Docker
docker run -i --rm antobrugnot/qrcode-mcp-server:latest
# Avec Podman (plus sécurisé)
podman run -i --rm antobrugnot/qrcode-mcp-server:latest
# Avec Docker Compose
docker-compose up qrcode-mcp-server
# Avec Podman Compose
podman-compose up qrcode-mcp-server
# Mode développement
docker-compose --profile dev up qrcode-mcp-dev
# ou
podman-compose --profile dev up qrcode-mcp-dev# Mode développement avec rechargement automatique
npm run dev
# Ou en mode watch
npm run watch
# Builder pour la production
npm run build
# Lancer la version buildée
npm startgenerate-qrcode-dataurlGénère un QR code et le retourne sous forme de Data URL (base64).
Paramètres :
text (string, requis) : Le texte ou URL à encoder
options (object, optionnel) : Options de génération
errorCorrectionLevel : 'L', 'M', 'Q', ou 'H' (défaut: 'M')
width : Largeur en pixels (50-2000)
margin : Marge en modules (0-10, défaut: 4)
color.dark : Couleur des modules sombres (défaut: '#000000')
color.light : Couleur de l'arrière-plan (défaut: '#FFFFFF')
type : Type MIME ('image/png', 'image/jpeg', 'image/webp')
Exemple d'utilisation :
{
"text": "https://github.com",
"options": {
"width": 300,
"errorCorrectionLevel": "H",
"color": {
"dark": "#1f2937",
"light": "#f3f4f6"
}
}
}generate-qrcode-svgGénère un QR code au format SVG.
Paramètres :
text (string, requis) : Le texte ou URL à encoder
options (object, optionnel) : Options de génération (similaires à dataurl)
Exemple d'utilisation :
{
"text": "Hello, World!",
"options": {
"width": 200,
"margin": 2
}
}generate-qrcode-terminalGénère un QR code pour affichage dans le terminal.
Paramètres :
text (string, requis) : Le texte ou URL à encoder
options (object, optionnel) :
small (boolean) : Utiliser le format compact (défaut: false)
Exemple d'utilisation :
{
"text": "Terminal QR Code",
"options": {
"small": true
}
}generate-qrcode-batchGénère plusieurs QR codes en une seule opération (maximum 10).
Paramètres :
texts (array[string], requis) : Tableau de textes/URLs à encoder (max 10)
format (string, optionnel) : Format de sortie ('dataurl', 'svg', 'terminal', défaut: 'dataurl')
options (object, optionnel) : Options de génération
Exemple d'utilisation :
{
"texts": [
"https://github.com",
"https://www.google.com",
"Hello World"
],
"format": "dataurl",
"options": {
"width": 200
}
}ℹ️ Astuce GitHub Copilot :
Pour GitHub Copilot, la clémcpServersdans la configuration devient simplementservers.
Ajoutez cette configuration à votre claude_desktop_config.json :
{
"mcpServers": {
"qrcode-generator": {
"command": "docker",
"args": ["run", "-i", "--rm", "antobrugnot/qrcode-mcp-server:latest"]
}
}
}Ou avec Podman (plus sécurisé, rootless) :
{
"mcpServers": {
"qrcode-generator": {
"command": "podman",
"args": ["run", "-i", "--rm", "antobrugnot/qrcode-mcp-server:latest"]
}
}
}{
"mcpServers": {
"qrcode-generator": {
"command": "node",
"args": ["/chemin/vers/qrcode-mcp/dist/index.js"]
}
}
}Le serveur utilise le transport stdio standard et peut être utilisé avec n'importe quel client MCP compatible.
Générez un QR code pour "https://github.com"Générez un QR code pour "Mon site web" avec une largeur de 400px et des couleurs personnalisées (sombre: #2563eb, clair: #eff6ff)Générez des QR codes pour ces URLs : https://github.com, https://stackoverflow.com, https://nodejs.orgGénérez un QR code terminal pour "Test terminal" en format compactContainer sécurisé : Utilisation d'un utilisateur non-root (UID 1001)
Image Alpine : Image de base minimale pour réduire la surface d'attaque
Capabilities limitées : Suppression de toutes les capabilities Linux non nécessaires
Read-only filesystem : Container en lecture seule pour prévenir les modifications
Resource limits : Limites CPU et mémoire pour éviter les attaques DoS
Security scanning : Scan automatique des vulnérabilités avec Trivy
Dependency audit : Vérification automatique des dépendances npm
Multi-stage build : Build optimisé sans outils de développement en production
Utilisez toujours la dernière version taguée
Vérifiez régulièrement les mises à jour de sécurité
Surveillez les alertes GitHub Security
Utilisez des secrets GitHub pour les tokens DockerHub
Tests automatiques : TypeScript, build et audits de sécurité
Build multi-architecture : Support AMD64 et ARM64
Push automatique : DockerHub avec tags appropriés
Scan de sécurité : Trivy pour détecter les vulnérabilités
Release automatique : GitHub Releases avec notes générées
# Dans GitHub Secrets
DOCKERHUB_TOKEN=your_dockerhub_tokenqrcode-mcp/
├── .github/
│ └── workflows/ # GitHub Actions CI/CD
├── scripts/
│ └── release.sh # Script de release
├── src/
│ └── index.ts # Serveur MCP principal
├── dist/ # Fichiers compilés
├── Dockerfile # Configuration Docker
├── docker-compose.yml # Orchestration Docker
├── .dockerignore # Exclusions Docker
├── package.json # Dépendances et scripts
├── tsconfig.json # Configuration TypeScript
├── CONFIGURATION.md # Guide de configuration
└── README.md # DocumentationNode.js : Runtime JavaScript
TypeScript : Typage statique
@modelcontextprotocol/sdk : SDK MCP officiel
qrcode : Bibliothèque de génération de QR codes
zod : Validation de schémas
L (Low) : ~7% de récupération d'erreur
M (Medium) : ~15% de récupération d'erreur (recommandé)
Q (Quartile) : ~25% de récupération d'erreur
H (High) : ~30% de récupération d'erreur
Assurez-vous d'avoir installé les dépendances :
npm installVérifiez la configuration dans tsconfig.json et rebuilder :
npm run buildVérifiez que Node.js 18+ est installé :
node --version# Utiliser le script de release
./scripts/release.sh v1.0.0
# Ou déclencher manuellement via GitHub Actions
# GitHub → Actions → Release → Run workflowValidation : Tests, build et vérifications
Versioning : Mise à jour package.json et création du tag
Docker Build : Build et push multi-architecture
Security Scan : Analyse de sécurité avec Trivy
GitHub Release : Création avec notes automatiques
Notification : Confirmation du succès
# Dernière version stable
docker pull antobrugnot/qrcode-mcp-server:latest
# Version spécifique
docker pull antobrugnot/qrcode-mcp-server:v1.0.0
# Version de développement (branch develop)
docker pull antobrugnot/qrcode-mcp-server:developLes contributions sont les bienvenues ! N'hésitez pas à ouvrir une issue ou soumettre une pull request.
Fork le projet
Créer une branche feature (git checkout -b feature/amazing-feature)
Commiter vos changements (git commit -m 'Add amazing feature')
Pousser vers la branche (git push origin feature/amazing-feature)
Ouvrir une Pull Request
Utilisez TypeScript avec strict mode
Suivez les conventions ESLint/Prettier
Ajoutez des tests pour les nouvelles fonctionnalités
Mettez à jour la documentation si nécessaire
MIT License - voir le fichier LICENSE pour plus de détails.
Generate multiple QR codes from an array of texts or URLs
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format for QR codes | dataurl |
| options | No | QR code generation options | |
| texts | Yes | Array of texts or URLs to encode (max 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic function without disclosing behavioral traits. It doesn't mention output format (e.g., array of data URLs), performance implications of batch generation, error handling for invalid inputs, or any rate limits—critical gaps for a batch operation 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and input, making it easy to parse quickly.
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, no output schema, and a batch operation with nested parameters, the description is incomplete. It doesn't explain what the tool returns (e.g., an array of QR codes in the specified format), error conditions, or how batch processing differs behaviorally from single generation, leaving significant gaps for an AI 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%, so parameters are well-documented in the schema. The description adds minimal value by mentioning 'array of texts or URLs' which aligns with the 'texts' parameter, but doesn't provide additional context beyond what the schema already specifies, 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 clearly states the action ('generate multiple QR codes') and the input source ('from an array of texts or URLs'), which is specific and actionable. However, it doesn't explicitly differentiate from its siblings (generate-qrcode-dataurl, generate-qrcode-svg, generate-qrcode-terminal) which appear to be single-output variants, missing full sibling distinction.
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 its siblings or alternatives. It doesn't mention scenarios like batch processing needs, performance considerations, or differences from the single-output tools, leaving usage context entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a QR code from text or URL and return it as a base64 data URL
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | QR code generation options | |
| text | Yes | The text or URL to encode in the QR code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool generates and returns a QR code, implying a read-only operation, but doesn't cover aspects like performance (e.g., size limits on input text), error handling, or whether it's idempotent. This leaves gaps for a tool with configurable options.
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 that front-loads the core functionality ('generate a QR code') and specifies the input ('from text or URL') and output ('as a base64 data URL') without any wasted words. Every part 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 the tool's moderate complexity (2 parameters with nested objects, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and output format, but lacks usage guidelines, behavioral details, and doesn't compensate for the missing output schema (e.g., what the data URL structure looks like).
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 fully documents both parameters (text and options with nested properties). The description adds minimal value by mentioning 'text or URL' and 'base64 data URL', but doesn't explain parameter interactions or provide examples. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('generate'), resource ('QR code'), and output format ('base64 data URL'), which distinguishes it from siblings that produce different formats (SVG, terminal, batch). However, it doesn't explicitly mention that it generates a single QR code versus batch processing, which is a minor gap in sibling differentiation.
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 its siblings (generate-qrcode-batch, generate-qrcode-svg, generate-qrcode-terminal). It doesn't mention use cases like needing a data URL for web embedding versus SVG for vector graphics or batch processing for multiple codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a QR code from text or URL and return it as SVG format
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | QR code generation options | |
| text | Yes | The text or URL to encode in the QR code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the output format (SVG) but doesn't describe other behavioral traits like whether this is a read-only operation, potential rate limits, error handling, or what happens with invalid input. For a generation tool with zero annotation coverage, this leaves significant gaps.
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 that states the core functionality without unnecessary words. It's appropriately sized and front-loaded with the essential 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 tool's moderate complexity (2 parameters, nested objects) and 100% schema coverage but no annotations or output schema, the description is minimally adequate. It covers the basic purpose but lacks behavioral context and sibling differentiation that would make it more complete for agent 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 description coverage is 100%, so the schema already documents both parameters (text and options) thoroughly. The description adds minimal value beyond the schema - it mentions 'text or URL' which aligns with the schema's description, but doesn't provide additional context about parameter usage or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: 'Generate a QR code from text or URL and return it as SVG format.' It specifies the verb (generate), resource (QR code), and output format (SVG). However, it doesn't explicitly differentiate from its siblings (batch, dataurl, terminal variants), which would require a 5.
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 its siblings (generate-qrcode-batch, generate-qrcode-dataurl, generate-qrcode-terminal). It doesn't mention alternatives, exclusions, or specific contexts for choosing SVG output over other formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a QR code from text or URL and display it in terminal format
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | Terminal display options | |
| text | Yes | The text or URL to encode in the QR code |
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 mentions the tool generates and displays a QR code in terminal format, but lacks details on behavioral traits such as error handling, performance characteristics (e.g., speed), or any limitations (e.g., maximum text length). This is a significant gap for a tool with no annotation coverage.
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 that is front-loaded with the core purpose. Every word earns its place, with no redundant or unnecessary information, 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?
Given the complexity (2 parameters, nested objects) and lack of annotations and output schema, the description is incomplete. It does not explain what the output looks like (e.g., ASCII art format), potential errors, or usage constraints, leaving gaps for effective tool invocation by an AI 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%, so the schema already documents both parameters ('text' and 'options' with 'small' boolean). The description adds minimal value by implying the 'text' parameter can be a URL, but does not provide additional syntax, format details, or context beyond what the schema specifies.
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 ('Generate a QR code'), the resource ('from text or URL'), and the specific output format ('display it in terminal format'). It distinguishes from sibling tools by specifying the terminal output format, unlike batch, data URL, or SVG generation 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 implies usage context by specifying 'terminal format,' which suggests this tool is for terminal-based applications. However, it does not explicitly state when to use this tool versus the sibling alternatives (e.g., for CLI vs. web use cases) or any prerequisites, leaving some ambiguity.
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. Dates show when Glama detected each change.
v1.0.0generate-qrcode-batchgenerate-qrcode-dataurlgenerate-qrcode-svggenerate-qrcode-terminalScored across 4 tools
Each tool has a clearly distinct purpose based on output format: batch generation, data URL, SVG, and terminal display. There is no ambiguity in functionality, as the descriptions specify unique return types or use cases.
All tool names follow a consistent verb_noun pattern with 'generate-qrcode-' prefix and a suffix indicating the output format (e.g., batch, dataurl, svg, terminal). This uniformity makes the set predictable and easy to understand.
With 4 tools, the server is well-scoped for QR code generation, covering key output formats and batch processing. Each tool earns its place without redundancy, fitting a typical range for a focused utility server.
The tool set covers common QR code generation needs across multiple formats and batch operations, with no dead ends. A minor gap exists in not including a tool for reading or decoding QR codes, but the generation surface is largely complete for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create and manage CodeQR short links, QR codes, and analytics from any MCP client.
Generate QR codes for URLs, PIX, Wi-Fi, vCards, WhatsApp and more. For AI agents.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/antoBrugnot/qrcode-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
