Quiver-MCP
quiver-mcp
Servidor MCP para QuiverAI: genera archivos SVG a partir de prompts de texto y vectoriza imágenes rasterizadas mediante IA, directamente desde Claude (o cualquier cliente compatible con MCP).
Ejemplos
Generados por Claude llamando a este MCP. Cada uno tomó ~60s con n: 3, temperature: 0.9. Ambos prompts están documentados en la descripción de la herramienta, por lo que Claude conoce la receta.
Prompt: vista isométrica explosionada de una pluma estilográfica Montblanc Meisterstück, dibujo de plano técnico, arte de línea fina, fondo de cuadrícula de puntos, componentes etiquetados, ilustración de ingeniería
Prompt: grulla japonesa en estilo de ilustración de xilografía tradicional con tonos tierra cálidos
Instrucciones: usar una paleta cálida y apagada con trabajo detallado en las plumas
Más variantes en examples/.
Related MCP server: nakkas
Requisitos
Node.js 18+
Una clave de API de QuiverAI
Instalación
Claude Desktop
Añadir a tu claude_desktop_config.json:
{
"mcpServers": {
"quiverai": {
"command": "npx",
"args": ["-y", "@syntropic/quiver-mcp"],
"env": {
"QUIVERAI_API_KEY": "your_api_key_here"
}
}
}
}Manual
npm install -g @syntropic/quiver-mcp
QUIVERAI_API_KEY=your_api_key_here quiver-mcpHerramientas
generate_svg
Genera uno o más archivos SVG a partir de un prompt de texto.
Parámetro | Tipo | Requerido | Descripción |
| string | sí | Descripción textual del SVG a generar |
| string | sí | ID del modelo (usa |
| string | no | Orientación adicional de estilo o formato |
| number | no | Número de SVG a generar (predeterminado: 1) |
| number | no | Temperatura de muestreo 0–2 (predeterminado: 1) |
| array | no | Hasta 4 referencias de imagen ( |
| string | no | Ruta de archivo absoluta para guardar el/los SVG en el disco. Para múltiples variantes ( |
Consejos para los prompts
La descripción de la herramienta incluye una amplia guía de prompts, pero en resumen:
Estructura los prompts en tres partes: sujeto (objeto concreto), estilo (palabras clave estéticas como
line art,isometric,flat monochrome) y paleta de colores (códigos hexadecimales siempre que sea posible).Usa objetos físicos famosos que el modelo conozca. Evita conceptos abstractos de software (
AI agent,workflow); usa metáforas físicas en su lugar.Para explorar, genera 3+ variantes con
temperature: 0.9. Algunas generaciones producen colas corruptas; las variantes adicionales te dan opciones.
vectorize_svg
Convierte una imagen rasterizada (PNG, JPG, etc.) a SVG.
Parámetro | Tipo | Requerido | Descripción |
| string | sí | ID del modelo |
| object | sí | Imagen a vectorizar: |
| boolean | no | Recortar al sujeto dominante antes de vectorizar (predeterminado: false) |
| number | no | Objetivo de redimensionamiento cuadrado en píxeles antes de vectorizar |
| number | no | Temperatura de muestreo 0–2 (predeterminado: 1) |
| string | no | Ruta de archivo absoluta para guardar el SVG en el disco. Los directorios principales se crean automáticamente. |
list_models
Enumera todos los modelos de QuiverAI disponibles con las operaciones admitidas y los precios.
Variables de entorno
Variable | Descripción |
| Requerido. Tu clave de API de QuiverAI |
Desarrollo
npm install
npm run build # compile TypeScript
npm run dev # watch modeLicencia
MIT
Available Tools
3 toolsgenerate_svgA
Generate one or more SVGs from a text prompt using QuiverAI. Returns raw SVG markup.
Prompt guide
A good prompt has three parts: subject (specific object), style (aesthetic keywords), and color palette (hex codes if possible).
What works
Use concrete, famous physical objects the model has seen (AirPods, Nike Dunks, Shure SM7B, Montblanc pen, Leica camera, Nest thermostat, espresso machines). Cylindrical/round objects explode especially cleanly in isometric style.
Name the style explicitly: 'line art', 'hand drawn', 'duotone', 'flat monochrome icon', 'geometric', 'minimalist', 'isometric', 'blueprint'.
Specify colors with hex codes: 'background: #e9edc9 and logo in #fb8500'.
Add composition framing: 'centered icon', 'wide horizontal logo'.
Prompt modifiers: 'geometric' → angular shapes, 'detailed' → more elements, 'simple' → clearer shapes, 'minimalist' → fewer details, 'flat monochrome' → single-color, 'duotone' → two-color.
What does NOT work
NEVER mention 'AI', 'machine learning', 'voice assistant', 'workflow automation', or abstract software concepts — produces garbage. Use physical metaphors instead (microphone for voice, watch movement for precision).
Abstract concepts without physical objects: 'knowledge graph', 'automation pipeline', 'data flow'.
Obscure B2B hardware the model hasn't seen (e.g. Loxone Miniserver → generic blob).
'minimalist line icon' constraints — model ignores them and fills with color.
Iteration strategy
Start specific, not vague. Bad: 'Tech logo'. Better: 'Tech startup logo with geometric shapes, blue gradient'. Best: 'SaaS productivity logo with connected geometric nodes, electric blue to purple gradient, clean modern style'.
Verified template
exploded isometric view of a {FAMOUS_OBJECT}, technical blueprint drawing, thin line art, dotted grid background, labeled components, engineering illustration
Known issues
~1 in 10 generations have corrupted SVG tails (malformed XML). Generate 3+ variants as insurance.
Model may ignore 'no fills'/'monochrome' and hardcode its own palette. Post-process with find/replace for brand colors.
First call may 504 — retry succeeds.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | WHAT to generate. Be specific: name a concrete famous object, add style keywords, and specify colors with hex codes. Example: 'Heraldic lion crest with ornate medieval style details and gold gradient accents'. Never use abstract concepts like 'AI agent' or 'workflow' — use physical metaphors instead. | |
| model | Yes | Model ID to use. Recommended: 'arrow-preview' (Arrow 1.0, #1 on SVG Arena). Use list_models to discover all options. | |
| instructions | No | HOW it should look — style guidance separate from the subject. Think of prompt as 'what' and instructions as 'how'. Example: prompt='Japanese crane', instructions='Use a warm muted palette with detailed feather work'. | |
| n | No | Number of SVG variants to generate (max 16). Recommended: 3+ at higher temperature for best results, since ~1 in 10 generations can have corrupted tails. | |
| temperature | No | Sampling temperature (0–2). Lower (0.4) = more consistent, higher (0.9) = more creative variation. Use 0.9 with n≥3 for exploration. | |
| references | No | Up to 4 reference images for style, color, and composition guidance. References pull palette/color hints from the image, but style keywords ('blueprint', 'isometric', 'flat') must still be in the text prompt — references alone won't change drawing style. | |
| outputPath | No | Optional absolute file path to save the SVG(s) to disk. If omitted, SVG markup is returned in the response only. For multiple variants (n > 1), files are saved with _1, _2 … suffixes. Parent directories are created automatically. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it mentions return format (raw SVG markup), corruption rate (~1 in 10), timeout behavior (504 with retry), and model's tendency to ignore palette constraints. This gives the agent a clear understanding of tool behavior.
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 long but well-structured with clear headings and sections. It front-loads the core purpose and then provides detailed guidance. While verbose, every section serves a purpose; however, some redundancy could be trimmed for brevity.
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 complexity (7 parameters, no output schema, no annotations), the description is remarkably complete. It covers prompt crafting, iteration strategies, known issues, and error recovery. The 'Prompt guide' alone provides rich context that an agent needs to succeed.
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?
Although schema description coverage is 100%, the description adds substantial value beyond schema. The 'Prompt guide' provides concrete examples, do's and don'ts, and detailed reasoning for parameters like n and temperature. It also explains how references work and their limitations, which the schema does not fully convey.
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 'Generate one or more SVGs from a text prompt using QuiverAI. Returns raw SVG markup.' It specifies the verb (generate), resource (SVGs), and distinguishes from sibling tools like list_models and vectorize_svg.
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 extensive guidelines on when and how to use, including prompt structure, what works, what does not work, iteration strategy, and a verified template. It also covers known issues like corrupted tails and 504 errors, giving failure recovery guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_modelsA
List all models available on QuiverAI, including supported operations (svg_generate, svg_vectorize, etc.) and pricing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description is straightforward (list only). Does not mention read-only nature or auth requirements, but these are implicit for a list operation.
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?
Single sentence, no wasted words, front-loaded with purpose.
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 list tool with no parameters and no output schema. Describes what is included (operations, pricing). Could mention output format but not critical.
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 in schema; baseline for 0 params is 4. Description adds no param info (none needed).
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?
Clearly states verb (List), resource (models), and includes what info is returned (supported operations and pricing). Distinguishes from siblings generate_svg and vectorize_svg which are different actions.
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?
Implied usage: use to discover available models before generating or vectorizing. No explicit when-not-to-use or alternatives, but context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vectorize_svgA
Convert a raster image (PNG, JPG, etc.) into an SVG using QuiverAI. Provide the image as a URL or base64-encoded string.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model ID to use. Use list_models to find models that support svg_vectorize. | |
| image | Yes | The image to vectorize — either a URL or base64 data. | |
| autoCrop | No | Auto-crop to the dominant subject before vectorizing. Defaults to false. | |
| targetSize | No | Square resize target in pixels before vectorizing. | |
| temperature | No | Sampling temperature (0–2). Defaults to 1. | |
| outputPath | No | Optional absolute file path to save the vectorized SVG to disk. If omitted, SVG markup is returned in the response only. Parent directories are created automatically. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden; it lacks details on failure modes, rate limits, output quality, or side effects beyond basic conversion.
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 extraneous information—efficient and clear.
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 basic purpose and input method but omits return value format, side effects of optional parameters, and behavioral traits; adequate given schema coverage but incomplete.
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 detailed parameter descriptions, so description adds no new semantics beyond mentioning input image formats; baseline score 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?
Description clearly states the tool converts raster images (PNG, JPG) to SVG using QuiverAI, distinguishing it from sibling generate_svg which likely creates SVGs from scratch.
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?
Implies usage when a raster image needs conversion, but no explicit guidance on when not to use or alternatives like generate_svg or list_models.
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 updates
v0.1.0- First observed
generate_svg - First observed
list_models - First observed
vectorize_svg
TDQS
Scored across 3 tools
Each tool has a distinct purpose: generating SVGs from prompts, listing models, and vectorizing images. There is no overlap.
All tool names follow consistent snake_case with verb_noun pattern (generate_svg, list_models, vectorize_svg).
Three tools is on the low side but reasonable for a focused server. The scope is narrow enough that each tool earns its place.
Core SVG creation (from text and images) and model listing are covered, but missing operations like fetching/updating/deleting individual SVGs or batch processing.
Maintenance
Related MCP Connectors
Create professional SVG artwork, icons and vector logos from a prompt, or vectorize any image.
Generate and vectorize clean, editable SVG graphics from text, images, or both.
Visual AI for strategic thinking — SWOT, flowcharts, mindmaps, Gantt diagrams as polished SVG.
Generate PWA icon sets and iOS splash screens from a text prompt or an existing image.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables creation, validation, rendering, and optimization of SVG images with conversion capabilities to PNG, React components, React Native components, and Data URIs.-
- AlicenseAqualityBmaintenanceMCP server that turns AI into an SVG artist. One rendering engine with a rich JSON schema, AI controls all design parameters. Renders animated SVGs with CSS @keyframes and SMIL animations. Supports 16+ element types, parametric curves, pattern groups, gradient/filter/clip/mask definitions, and PNG preview. No external dependencies, runs locally via npx.3228 npm24MIT
- FlicenseNot gradedqualityDmaintenanceProvides tools to generate SVG vector graphics from text prompts and convert raster images into vector formats using the Quiver AI API. It enables seamless integration of vector graphic creation and image vectorization directly within MCP-compatible clients.-
- AlicenseNot gradedqualityDmaintenanceGenerates SVGs from text prompts and converts raster images to SVG using the Quiver AI API.2MIT