de en es ja ko ru zh

nakkas

Name: nakkas
Author: arikusi

by arikusi

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

nakkaş bedeutet auf Türkisch (alt) Maler/Künstler.

"make a neon terminal logo with animated binary digits"
  → AI constructs JSON config
  → nakkas renders to animated SVG
  → clean animated SVG output

Warum

Ein Werkzeug, unendliche Designs. render_svg akzeptiert eine JSON-Konfiguration. Die KI füllt alles aus.
KI-natives Schema. Jedes Feld hat .describe()-Annotationen, damit das Modell weiß, was zu tun ist.
Reines deklaratives SVG. CSS @keyframes + SMIL-Animationen, kein JavaScript.
Keine externen Abhängigkeiten. Keine Cloud-API, keine API-Schlüssel. Läuft lokal.

Related MCP server: inkscape_mcp

Installation

Claude Desktop

Fügen Sie dies Ihrer Konfigurationsdatei hinzu:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "nakkas": {
      "command": "npx",
      "args": ["-y", "nakkas@latest"]
    }
  }
}

Claude Code (CLI)

claude mcp add nakkas npx nakkas@latest

Cursor / Zed / Andere MCP-Clients

{
  "mcpServers": {
    "nakkas": {
      "command": "npx",
      "args": ["-y", "nakkas@latest"]
    }
  }
}

Lokale Entwicklung

git clone https://github.com/arikusi/nakkas
cd nakkas
npm install && npm run build
# Use dist/index.js as the command

Schnellstart

Fragen Sie Ihre KI (mit verbundenem Nakkas):

"Erstelle ein animiertes SVG: dunkler Terminal-Rahmen (800×200), leuchtend cyanfarbener Text 'NAKKAS', Neon-Glow-Filter, Einblenden beim Laden."

"Erstelle einen Lade-Spinner: einen Kreis mit einer Zeichen-Animation für den Pfad, die alle 1,5 Sekunden wiederholt wird."

"Datenvisualisierung: animiertes Balkendiagramm, 5 Balken, jeder mit einer gestaffelten Verzögerung eingeblendet, Farbverläufe."

"Profil-Badge (400×120): Blau-zu-Lila-Verlauf, weißer Benutzername, Schlagschatten, dezente Puls-Animation."

Werkzeuge

Nakkas bietet drei Werkzeuge:

Werkzeug	Zweck
`render_svg`	Akzeptiert SVGConfig JSON, gibt SVG-String + Designanalyse-Warnungen zurück
`preview`	Akzeptiert gerenderten Inhalt, gibt ein PNG-Bild zur visuellen Überprüfung zurück
`save`	Akzeptiert gerenderten Inhalt, speichert als SVG (Text) oder PNG (Raster) auf der Festplatte

Der beabsichtigte Arbeitsablauf: Rendern → Vorschau → Iterieren → Speichern. Das save-Werkzeug ist von render_svg getrennt, um das Vorschauen und Verfeinern vor dem Speichern zu fördern.

Das `save`-Werkzeug

{ "content": "<svg ...>...</svg>", "outputPath": "./design.svg", "format": "auto" }

Formate: auto (wird aus der Endung abgeleitet), svg (Textdatei), png (rendert zuerst zu Raster). Wenn die Datei existiert, wird ein numerischer Zähler angehängt, um ein Überschreiben zu verhindern. Der tatsächliche Speicherpfad wird zurückgegeben.

Das `render_svg`-Werkzeug

Eingabe: SVGConfig JSON-Objekt Ausgabe: Vollständiger SVG-XML-String plus optionale Designanalyse-Notizen

Nach dem Rendern kann die Antwort Designwarnungen zu häufigen Problemen enthalten, wie z. B. zu viele gleichzeitige Animationen, fehlende transformBox oder Skalierungstransformationen auf Gruppenebene.

SVGConfig-Struktur

{
  canvas: {
    width: number | string,   // e.g. 800 or "100%"
    height: number | string,
    viewBox?: string,          // "0 0 800 400"
    background?: string        // hex "#111111" or "transparent"
  },

  defs?: {
    gradients?: Gradient[],   // linearGradient | radialGradient
    filters?: Filter[],        // preset or raw primitives
    clipPaths?: ClipPath[],
    masks?: Mask[],
    symbols?: Symbol[],
    paths?: { id, d }[]       // for textPath elements
  },

  elements: Element[],         // shapes, text, groups, use instances

  animations?: CSSAnimation[]  // CSS @keyframes definitions
}

Elementtypen

Typ	Erforderliche Felder	Hinweise
`rect`	`width`, `height`	`x`, `y` standardmäßig 0; `rx`/`ry` für abgerundete Ecken
`circle`	`r`	`cx`, `cy` standardmäßig 0
`ellipse`	`rx`, `ry`	Unabhängige horizontale/vertikale Radien
`line`	`x1`, `y1`, `x2`, `y2`
`polyline`	`points`	Offener Pfad: `"10,20 50,80 90,20"`
`polygon`	`points`	Automatisch geschlossene Form
`path`	`d`	Vollständige SVG-Pfadbefehle
`image`	`href`, `width`, `height`	URL oder `data:image/...` URI für eingebettete Bilder
`text`	`content`	String oder `(string \| Tspan)[]` Array
`textPath`	`pathId`, `text`	Text entlang einer Kurve; Pfad definiert in `defs.paths`
`group`	`children`	Gemeinsame Attribute für alle Kinder (keine verschachtelten Gruppen)
`use`	`href`	Instanziiert ein Symbol oder klont ein Element per `#id`
`radial-group`	`cx`, `cy`, `count`, `radius`, `child`	Platziert N Kopien um einen vollen Kreis
`arc-group`	`cx`, `cy`, `radius`, `count`, `startAngle`, `endAngle`, `child`	Platziert N Kopien entlang eines Kreisbogens
`grid-group`	`cols`, `rows`, `colSpacing`, `rowSpacing`, `child`	Platziert Kopien in einem M-mal-N-Gitter
`scatter-group`	`width`, `height`, `count`, `seed`, `child`	Verteilt N Kopien an zufälligen Positionen (mit Seed)
`path-group`	`waypoints`, `count`, `child`	Verteilt N Kopien gleichmäßig entlang einer Polylinie
`parametric`	`fn`	Mathematische Kurve: `rose`, `heart`, `star`, `lissajous`, `spiral`, `superformula`, `epitrochoid`, `hypotrochoid`, `wave`

Alle visuellen Elemente (Gemeinsame Felder)

{
  id?: string,             // required for filter/gradient/clip references
  cssClass?: string,       // matches CSS animation names
  fill?: string,           // "#rrggbb" | "none" | "url(#gradId)"
  stroke?: string,
  strokeWidth?: number,
  strokeDasharray?: string, // "10 5", use for draw-on animation
  strokeDashoffset?: number,
  opacity?: number,        // 0–1
  filter?: string,         // "url(#filterId)"
  clipPath?: string,       // "url(#clipId)"
  transform?: string,      // "rotate(45)" "translate(100, 50)"
  transformBox?: "fill-box" | "view-box" | "stroke-box",  // set "fill-box" for CSS rotation
  transformOrigin?: string, // "center", works with fill-box
  smilAnimations?: SMILAnimation[]
}

Filter-Presets

Referenzieren Sie als filter: "url(#myId)" auf jedem Element, nachdem Sie es in defs.filters definiert haben:

{ "type": "preset", "id": "myGlow", "preset": "glow", "stdDeviation": 8, "color": "#ff00ff" }

Preset	Schlüsselparameter	Effekt
`glow`	`stdDeviation`, `color`	Weicher Heiligenschein
`neon`	`stdDeviation`, `color`	Intensives helles Leuchten
`blur`	`stdDeviation`	Gaußscher Weichzeichner
`drop-shadow`	`stdDeviation`, `offsetX`, `offsetY`, `color`	Schlagschatten
`glitch`	`stdDeviation`	Turbulenz-Verschiebung (animiert)
`grayscale`	`value` (0–1)	Entsättigen
`sepia`	—	Warmer Sepia-Ton
`invert`	—	Farben invertieren
`saturate`	`value`	Sättigung erhöhen/verringern
`hue-rotate`	`value` (Grad)	Farbton verschieben
`chromatic-aberration`	`value` (px-Versatz, Standard 3)	RGB-Kanal-Split für Linsenverzerrungs-Look
`noise`	`value` (Deckkraft 0 bis 1, Standard 0.25)	Filmkorn- und Textur-Overlay
`outline`	`color`, `value` (Dicke, Standard 2)	Farbiger Umriss um das Element
`inner-shadow`	`color`, `stdDeviation`, `value` (Deckkraft, Standard 0.5)	Schatten innerhalb des Elements
`emboss`	`stdDeviation`, `value` (Intensität, Standard 1.5)	3D-Relief-Schattierungseffekt

CSS-Animationen

{
  "animations": [{
    "name": "pulse",
    "duration": "2s",
    "iterationCount": "infinite",
    "direction": "alternate",
    "keyframes": [
      { "offset": "from", "properties": { "opacity": "0.3", "transform": "scale(0.9)" } },
      { "offset": "to",   "properties": { "opacity": "1",   "transform": "scale(1.1)" } }
    ]
  }],
  "elements": [{
    "type": "circle",
    "cx": 100, "cy": 100, "r": 40,
    "cssClass": "pulse",
    "transformBox": "fill-box",
    "transformOrigin": "center"
  }]
}

CSS-Eigenschaftsschlüssel: camelCase (strokeDashoffset) oder kebab-case (stroke-dashoffset). Beides funktioniert.

Animierbare CSS-Eigenschaften: opacity, fill, stroke, transform, filter, clip-path, stroke-dasharray, stroke-dashoffset, font-size, letter-spacing und mehr.

SMIL-Animationen

Drei SMIL-Typen, inline definiert auf jedem Element via smilAnimations: []:

{ "kind": "animate",          "attributeName": "d",       "from": "...", "to": "...", "dur": "2s" }
{ "kind": "animateTransform", "type": "rotate",            "from": "0 100 100", "to": "360 100 100", "dur": "3s" }
{ "kind": "animateMotion",    "path": "M 0 0 C ...",      "dur": "4s", "rotate": "auto" }

Pfad-Morphing (attributeName: "d"): Von/Zu-Pfade müssen identische Befehlstypen und Anzahlen haben. Nur Koordinaten können variieren.

Schriftarten

Systemschriftarten funktionieren überall ohne Laden: Arial, Helvetica, Courier New, Georgia, Verdana, monospace, sans-serif, serif.

Benutzerdefinierte Schriftfamilien werden ebenfalls akzeptiert. Sie funktionieren, wenn die Schriftart in der Rendering-Umgebung verfügbar ist (Webseite mit geladenen Schriftarten, Design-Tool usw.).

Anwendungsfälle & Kompatibilität

Kontext	CSS @keyframes	SMIL	Externe Schriftarten	Interaktiv (onclick)
GitHub README `<img>`	✅	✅	❌	❌
Webseite `<img>`	✅	✅	❌	❌
Webseite Inline-SVG	✅	✅	✅	✅
Design-Tool-Export	✅	✅	✅	—
Statischer Datei-Viewer	✅	✅	abhängig	abhängig

Fehlerbehebung

"MCP error -32602: Input validation error"

Dies bedeutet, dass das MCP-SDK die Eingabe abgelehnt hat, bevor sie den Handler erreichte. Es passiert normalerweise beim ersten Versuch und funktioniert beim erneuten Versuch. Die häufigsten Auslöser:

Tippfehler beim Verlaufstyp. Verwenden Sie "linearGradient" oder "radialGradient", nicht "linear" oder "radial". Dies ist der häufigste Fehler.
Keyframe-Offset als String. Schreiben Sie 0 oder 100 (Zahlen) oder "from" / "to". Das Schreiben von "0%" oder "100%" führt zu einem Fehler.
Benannte Farben. Nur Hex-Werte funktionieren: "#ff0000", nicht "red". Auch kein rgb().
Fehlender type bei Elementen. Jedes Elementobjekt benötigt ein type-Feld.

Wenn Sie eine MCP-Client-Integration erstellen und dies konsistent sehen, liegt das Problem wahrscheinlich an der Art und Weise, wie Ihr Client Argumente serialisiert. Siehe anthropics/claude-code#29104 für Kontext zu bekannten Serialisierungs-Eigenheiten.

Vorschau zeigt ein leeres oder unerwartetes Bild

Das Vorschau-Tool rendert einen statischen Schnappschuss bei t=0. Animationen werden nicht erfasst. Was Sie sehen, ist der Anfangszustand des SVGs, bevor eine CSS- oder SMIL-Animation beginnt.

Wenn das Bild komplett leer ist:

Überprüfen Sie, ob Ihre Elemente fill oder stroke gesetzt haben. Eine Form ohne Füllung auf einer transparenten Leinwand ist unsichtbar.
Überprüfen Sie die Koordinaten. Ein Element bei x: 2000 auf einer 800px breiten Leinwand ist einfach außerhalb des Bildschirms.
Wenn Sie filter: "url(#myFilter)" verwenden, stellen Sie sicher, dass myFilter tatsächlich in defs.filters definiert ist.

Animationen funktionieren nicht auf GitHub

GitHub READMEs rendern SVG über <img>-Tags, die JavaScript entfernen, aber CSS und SMIL beibehalten. Wenn Ihre Animation lokal funktioniert, aber nicht auf GitHub:

Vermeiden Sie <script> oder Event-Handler (onclick, onmouseover). Diese werden entfernt.
Externe Schriftarten werden nicht geladen. Bleiben Sie bei Systemschriftarten: Arial, Courier New, Georgia, monospace, sans-serif.
CSS @import für Schriftarten ist blockiert. Wenn Sie eine bestimmte Schriftart benötigen, verwenden Sie inline <text> mit einem System-Fallback.

Große SVG-Ausgabe

Wenn render_svg eine Warnung zur Dateigröße (über 50kb) zurückgibt, erzeugen die parametrischen Kurven oder Mustergruppen wahrscheinlich zu viele Elemente. Reduzieren Sie steps bei parametrischen Kurven oder count bei Mustergruppen. Eine grid-group mit cols: 50, rows: 50 erzeugt 2500 Elemente, was sich schnell summiert.

Tech-Stack

TypeScript + Node.js 18+
@modelcontextprotocol/sdk (MCP-Server)
zod

Available Tools

3 tools

previewPreview SVGA

Render SVG content to a PNG image so the AI can visually inspect the output.

When to use:

render_svg already returns a preview image by default; call this tool to re-preview a stored artifact at a different width, or to preview SVG that did not come from render_svg
Stop iterating when the visual result matches the intent

Input: pass EITHER artifact (id from render_svg, e.g. "art-1" — preferred, no SVG resend) OR content (raw SVG string).

Behavior:

Returns a PNG image (base64) rendered from the SVG
Background is transparent by default
CSS animations and SMIL are rendered as a static snapshot (t=0) — motion is not captured

Width:

Omit width to use the SVG's own declared width/viewBox
Pass width to scale the output (useful for small SVGs that need a larger preview)

ParametersJSON Schema

Name	Required	Description
`width`	No	Render width in pixels; defaults to SVG's own declared width
`format`	No	Content format; auto-detected from content if omitted
`content`	No	SVG string to render as PNG. Only needed when no artifact id exists.
`artifact`	No	Artifact id returned by render_svg (e.g. "art-1"). Preferred over content.

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the output is a PNG base64, background is transparent, animations are static snapshots, and width can be omitted or specified. It does not contradict any annotations (none provided). However, it does not explain the 'format' parameter's effect (e.g., when to use 'html') though schema covers it.

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?

The description is well-structured with sections (When to use, Input, Behavior, Width), front-loaded with purpose, and every sentence adds value without unnecessary text.

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 4 optional parameters, no output schema, and no annotations, the description covers key behaviors and usage contexts. It does not explicitly state mutual exclusivity of artifact and content, but the 'pass EITHER' guidance implies it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so baseline is 3. The description adds meaning by explaining that 'artifact' is preferred over 'content', width can be left to default, and content is only needed when no artifact id exists.

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?

The description states clearly 'Render SVG content to a PNG image so the AI can visually inspect the output.' It distinguishes from sibling tool render_svg by noting that render_svg already returns a preview and this tool is for re-previewing or previewing external SVG.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'When to use' section explicitly tells when to use this tool vs render_svg, including re-previewing artifacts or previewing SVG from other sources. It also advises to stop iterating when visual result matches intent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

render_svgRender SVGA

Render animated SVG from JSON config. AI controls all design parameters.

Workflow: render_svg returns a PNG preview of the result plus an artifact id — critique the image, revise the config, render again. Iterate at least 3 times before finalizing. The SVG text stays on the server: pass the artifact id to save (and to preview for a different width). Add output:{svg:true} only if you actually need the SVG text in the conversation.

output options (response shape, not content): {"svg":false,"preview":true,"previewWidth":800,"minify":false,"frames":4} — all optional. minify:true collapses whitespace in the stored/saved SVG. frames:N (2-10) replaces the static preview with one filmstrip image sampling the CSS animations at N times — use it to verify motion (rotation direction, timing, easing) since a single preview only shows t=0. SMIL is not sampled.

Element types: rect, circle, ellipse, line, polyline, polygon, path, image, text, textPath, group, use, radial-group, arc-group, grid-group, scatter-group, path-group, parametric

Pattern groups (use for repetitive designs): radial-group (circular: cx, cy, radius, count), arc-group (arc: cx, cy, radius, count, startAngle, endAngle), grid-group (matrix: cols, rows, colSpacing, rowSpacing), scatter-group (random: width, height, count, seed), path-group (along polyline: waypoints, count). Each takes ONE "child" element.

Parametric curves (fn field): rose, heart, lissajous, spiral, star, superformula, epitrochoid, hypotrochoid, wave. Size via "scale" field. Server computes coordinates.

defs: gradients (linear/radial, SMIL animated stops), filters (presets: glow, neon, blur, drop-shadow, glitch, chromatic-aberration, noise, outline, inner-shadow, emboss + 5 more), clipPaths, masks, patterns (tile fills).

Animations: CSS @keyframes via animations array. Set cssClass on element matching animation name. For transforms add transformBox="fill-box" transformOrigin="center". SMIL via smilAnimations on elements (animate, animateTransform, animateMotion).

Critical format rules:

Gradient type must be "linearGradient" or "radialGradient" (not "linear"/"radial"). Each needs id, stops (array with offset 0-1, color).
Filter type must be "preset" with a "preset" field: {"type":"preset","id":"myGlow","preset":"glow","stdDeviation":8,"color":"#ff00ff"}
Keyframe offset: use "from"/"to" or percentage number 0-100 (not "0%"/"100%").
Gradient stop and filter colors: hex only (#rrggbb or #rrggbbaa). Element fill/stroke accept '#rrggbb', 'none', or 'url(#id)' (hex is safest).
Every element needs "type" field. circle needs r, rect needs width+height, path needs d.

Field names that differ from raw SVG:

text: string goes in "content" (not "text"): {"type":"text","x":100,"y":50,"content":"Hello","fontSize":24,"textAnchor":"middle"}
textPath: {"type":"textPath","pathId":"idFromDefsPaths","text":"..."} — here the field IS "text".
group: {"type":"group","children":[...]} — children are shapes/text/use only, no nested groups.
Pattern groups take ONE "child" element drawn at local origin (child uses cx=0/cy=0); set rotateChildren:false to keep text upright.

Output: Pure SVG XML. No JavaScript. CSS @keyframes + SMIL only.

ParametersJSON Schema

Name	Required	Description	Default
`defs`	No
`canvas`	Yes
`output`	No
`elements`	Yes
`animations`	No

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It transparently discloses that SVG text stays on the server (access via artifact id), describes output format (PNG preview + artifact id), explains field name differences from raw SVG, critical format rules, and the behavior of pattern groups and parametric curves. No contradictions.

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?

The description is long but well-structured with sections (Workflow, output options, element types, pattern groups, etc.). Every sentence adds necessary detail given the complexity of SVG rendering. Slightly verbose but justified; could be tightened without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 params, nested objects, no output schema), the description covers all essential aspects: input structure, workflow, output format, edge cases (field name differences, format rules), and usage of defs and animations. It explains return values (PNG preview + artifact id) despite no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. It provides extensive detail on each parameter group (canvas, elements, animations, output, defs) with examples, required fields, and format constraints (e.g., gradient type must be 'linearGradient', elements need 'type' field). This goes far beyond the bare schema.

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?

The description begins with 'Render animated SVG from JSON config', clearly stating the tool's core function. It distinguishes from siblings (preview, save) via workflow context, and the detailed enumeration of element types, animations, and output options reinforces the specific purpose.

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 provides an explicit iterative workflow ('critique, revise, render again, iterate at least 3 times'), explains when to use output options like 'svg:true', and when to preview for different widths. However, it doesn't explicitly state when not to use this tool relative to the sibling tools, though the context strongly implies it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

saveSave ContentA

Save rendered content to disk. Format-aware: can save as text or render to raster image.

IMPORTANT: Use this only AFTER iterating on the design with render_svg's preview images. Do not save on the first render. Preview and refine your work first.

Input: pass EITHER artifact (id from render_svg, e.g. "art-1" — preferred, no SVG resend) OR content (raw string).

Format detection:

'auto' (default): infers format from file extension. .svg saves as text, .png renders to image.
'svg': saves content as a UTF-8 text file
'png': renders the content (assumed SVG) to a PNG image, then saves it

If the file already exists, a numeric counter is appended before the extension to prevent overwriting: design.svg becomes design-1.svg, then design-2.svg. The actual saved path is returned in the response.

ParametersJSON Schema

Name	Required	Description	Default
`width`	No	For raster formats (png): render width in pixels. Defaults to the source content's own declared dimensions.
`format`	No	Output format. 'auto' infers from file extension (.svg saves as text, .png renders to image). 'svg' saves content as a UTF-8 text file. 'png' renders SVG content to a PNG image before saving.	auto
`content`	No	Raw content to save. Only needed when the content did not come from render_svg.
`artifact`	No	Artifact id returned by render_svg (e.g. "art-1"). Preferred over content.
`outputPath`	Yes	File path to save to. The directory must already exist. If the file already exists, a numeric counter is appended before the extension: design.svg becomes design-1.svg, then design-2.svg, and so on. The actual saved path is returned in the response.

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully discloses behaviors: format detection (auto, svg, png), file overwrite prevention with numeric counter, and input options (artifact vs content). No contradictions.

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?

Well-structured with sections, bullet points, and bolded keywords. Every sentence earns its place—no fluff. Efficiently communicates complex behavior in a few paragraphs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 params, no annotations, and no output schema, description covers all aspects: input selection, format handling, overwrite behavior, and return value. Complete enough for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds crucial context: width defaults to source dimensions, artifact is preferred over content, outputPath explains counter behavior, format enum values are elaborated. Adds significant value beyond schema.

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?

The description clearly states 'Save rendered content to disk' and distinguishes itself from siblings (preview, render_svg) by specifying it is for final saving after iterating on design.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this only AFTER iterating on the design with render_svg's preview images' and warns 'Do not save on the first render', providing clear usage context and when-not-to-use.

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.

1 tool updatev0.3.0Jul 9, 2026
- Changedrender_svg1 field changed
  - addedInput schema / properties / output / properties / frames
```
Added value: +{
+  "type": "number"
+}
```

3 tool updatesv0.2.0Jul 8, 2026

Changedpreview3 fields changed

addedInput schema / properties / artifact

Added value: +{
+  "description": "Artifact id returned by render_svg (e.g. \"art-1\"). Preferred over content.",
+  "type": "string"
+}

changedInput schema / properties / content / description

Previous value: -"SVG string to render as PNG"New value: +"SVG string to render as PNG. Only needed when no artifact id exists."

removedInput schema / required
```
Removed value: -[
-  "content"
-]
```

Changedrender_svg6 fields changed

changedInput schema / additionalProperties
```
Previous value: -falseNew value: +true
```
changedInput schema / properties / animations / items / additionalProperties
```
Previous value: -falseNew value: +true
```
changedInput schema / properties / animations / items / properties / keyframes / items / additionalProperties
```
Previous value: -falseNew value: +true
```
changedInput schema / properties / canvas / additionalProperties
```
Previous value: -falseNew value: +true
```
changedInput schema / properties / defs / additionalProperties
```
Previous value: -falseNew value: +true
```

addedInput schema / properties / output

Added value: +{
+  "additionalProperties": true,
+  "properties": {
+    "minify": {
+      "type": "boolean"
+    },
+    "preview": {
+      "type": "boolean"
+    },
+    "previewWidth": {
+      "type": "number"
+    },
+    "svg": {
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

Changedsave3 fields changed

addedInput schema / properties / artifact

Added value: +{
+  "description": "Artifact id returned by render_svg (e.g. \"art-1\"). Preferred over content.",
+  "type": "string"
+}

changedInput schema / properties / content / description

Previous value: -"Content to save. This is typically the output of a render tool such as render_svg."New value: +"Raw content to save. Only needed when the content did not come from render_svg."

changedInput schema / required

Previous value: -[
-  "content",
-  "outputPath"
-]New value: +[
+  "outputPath"
+]

1 tool updatev0.1.0May 3, 2026
- Changedrender_svg2 fields changed
  - removedInput schema / properties / animations / items / properties / keyframes / minItems
```
Removed value: -2
```
  - removedInput schema / properties / elements / minItems
```
Removed value: -1
```
3 tool updatesv0.1.3Mar 25, 2026
- First observedpreview
- First observedrender_svg
- First observedsave

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

A4.7/5.0

Scored 2026-09-09 19:39 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: render_svg generates SVG from config, preview renders existing or external SVG to PNG, and save persists rendered content. The overlap where render_svg includes a preview by default is explicitly handled by the preview tool's description, so no ambiguity exists.

Naming Consistency4/5

All names use lowercase snake_case and are short, but there is a minor deviation: render_svg follows verb_noun while preview and save are bare verbs. The pattern is still predictable and readable, with only a slight structural inconsistency.

Tool Count5/5

Three tools is well-scoped for a focused SVG rendering service. Each tool earns its place: render for creation, preview for inspection, save for persisting output. No unnecessary duplication or bloat.

Completeness5/5

The tool surface covers the full intended workflow: render generated content, preview it at different sizes or from external SVG, and save as text or image. There are no obvious dead ends or missing core operations for the server's stated purpose.

Maintenance

ActivityStale

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

mcp-flux-proOAuth
io.github.AceDataCloud
MCP server for Flux AI image generation
Image & Video Processing Multimedia Processing
23
mcp-wanOAuth
io.github.AceDataCloud
MCP server for Wan AI video generation
AI & Machine Learning Image & Video Processing
21
mcp-hailuoOAuth
io.github.AceDataCloud
MCP server for Hailuo (MiniMax) AI video generation
AI & Machine Learning Image & Video Processing
21
Idea to MotionOAuth
com.ideatomotion
Make animated videos by asking Claude, Cursor or any MCP client. Your AI writes it, we render it.
Image & Video Processing Multimedia Processing
1

Related MCP Servers

Generative-UI-MCP
Data Visualization Design Tools AI & Machine Learning
fergusalveolar205
A
license
A
quality
C
maintenance
Enables AI models to generate interactive visuals including charts, diagrams, UI mockups, and SVG graphics from plain text prompts. This Windows-based MCP server serves as an intermediary to bridge AI tools with visual output capabilities.
Updated 3 days ago (2026-09-19 07:24 UTC)
1
13 npm
MIT
inkscape_mcp
Design Tools Image & Video Processing
aravindev
A
license
Not graded
quality
A
maintenance
MCP server that lets AI agents drive Inkscape — interactively alongside the GUI or headlessly from the CLI
Updated 8 days ago (2026-09-14 06:12 UTC)
285 PyPI
62
MIT
genart-mcp
Art & Culture Design Tools
genart-dev
A
license
Not graded
quality
D
maintenance
MCP server for creating and manipulating generative art with p5.js, Three.js, GLSL, Canvas2D, and SVG, featuring workspace management, parameter control, and screenshot capture.
Updated 6 months ago (2026-03-29 06:47 UTC)
45 npm
MIT
Glyphic
CI/CD & DevOps Data Visualization Software Architecture
MS-Teja
A
license
A
quality
B
maintenance
An MCP server that lets agents draw 18 diagram types from JSON (no SVG, no headless browser)
Updated 2 months ago (2026-07-19 14:31 UTC)
2
31 npm
10
MIT

Appeared in Searches

A tool for designing beautiful, functional, and graphically rich HTML webpages using Tailwind CSS, JavaScript, and SVG

Warum

Installation

Claude Desktop

Claude Code (CLI)

Cursor / Zed / Andere MCP-Clients

Lokale Entwicklung

Schnellstart

Werkzeuge

Das save-Werkzeug

Das render_svg-Werkzeug

SVGConfig-Struktur

Elementtypen

Alle visuellen Elemente (Gemeinsame Felder)

Filter-Presets

CSS-Animationen

SMIL-Animationen

Schriftarten

Anwendungsfälle & Kompatibilität

Fehlerbehebung

"MCP error -32602: Input validation error"

Vorschau zeigt ein leeres oder unerwartetes Bild

Animationen funktionieren nicht auf GitHub

Große SVG-Ausgabe

Tech-Stack

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Das `save`-Werkzeug

Das `render_svg`-Werkzeug