nakkaşはトルコ語（古語）で画家/アーティストを意味します。
"make a neon terminal logo with animated binary digits"
→ AI constructs JSON config
→ nakkas renders to animated SVG
→ clean animated SVG output1つのツールで無限のデザイン。 render_svgはJSON設定を受け取ります。AIがすべてを埋めます。
AIネイティブなスキーマ。 すべてのフィールドに.describe()アノテーションがあるため、モデルは何をすべきかを理解しています。
純粋な宣言型SVG。 CSS @keyframes + SMILアニメーション、JavaScriptは不要です。
外部依存関係ゼロ。 クラウドAPIもAPIキーも不要。ローカルで実行されます。
Related MCP server: inkscape_mcp
設定ファイルに追加してください：
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 mcp add nakkas npx nakkas@latest{
"mcpServers": {
"nakkas": {
"command": "npx",
"args": ["-y", "nakkas@latest"]
}
}
}git clone https://github.com/arikusi/nakkas
cd nakkas
npm install && npm run build
# Use dist/index.js as the commandAIに（Nakkasを接続した状態で）尋ねてみてください：
"アニメーションSVGを作成して：ダークなターミナルフレーム（800×200）、光るシアンのテキスト「NAKKAS」、ネオン発光フィルター、読み込み時にフェードイン。"
"ローディングスピナーを作成して：1.5秒ごとにループする描画ストロークアニメーション付きの円。"
"データ可視化：アニメーション付き棒グラフ、5本のバー、それぞれがずらした遅延でフェードインし、グラデーション塗りつぶし。"
"プロフィールバッジ（400×120）：青から紫へのグラデーション、白いユーザー名テキスト、ドロップシャドウ、微かなパルスアニメーション。"
Nakkasは3つのツールを提供します：
ツール | 目的 |
| SVGConfig JSONを受け取り、SVG文字列とデザイン分析の警告を返します |
| レンダリングされたコンテンツを受け取り、視覚確認用のPNG画像を返します |
| レンダリングされたコンテンツを受け取り、SVG（テキスト）またはPNG（ラスター）としてディスクに保存します |
推奨されるワークフロー：レンダリング → プレビュー → 反復 → 保存。saveツールはrender_svgとは別に用意されており、保存前にプレビューと調整を促すようになっています。
save ツール{ "content": "<svg ...>...</svg>", "outputPath": "./design.svg", "format": "auto" }フォーマット：auto（拡張子から推論）、svg（テキストファイル）、png（先にラスターにレンダリング）。ファイルが存在する場合は、上書きを防ぐために数値カウンターが付加されます。実際に保存されたパスが返されます。
render_svg ツール入力: SVGConfig JSONオブジェクト
出力: 完全なSVG XML文字列とオプションのデザイン分析メモ
レンダリング後、レスポンスには、同時アニメーションが多すぎる、transformBoxが欠落している、グループレベルのスケール変換があるといった一般的な問題に関するデザイン警告が含まれる場合があります。
{
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
}タイプ | 必須フィールド | メモ |
|
|
|
|
|
|
|
| 水平/垂直半径を個別に指定 |
|
| |
|
| 開いたパス: |
|
| 自動的に閉じられる形状 |
|
| 完全なSVGパスコマンド |
|
| 埋め込み画像用のURLまたは |
|
| 文字列または |
|
| 曲線に沿ったテキスト; パスは |
|
| すべての子要素に適用される共有属性（ネストされたグループは不可） |
|
| シンボルのインスタンス化、または |
|
| 円全体にN個のコピーを配置 |
|
| 円弧に沿ってN個のコピーを配置 |
|
| M×Nグリッドにコピーを配置 |
|
| シード値に基づいたランダムな位置にN個のコピーを散布 |
|
| ポリラインに沿ってN個のコピーを均等に配置 |
|
| 数学的曲線: |
{
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[]
}defs.filtersで定義した後、任意の要素でfilter: "url(#myId)"として参照します：
{ "type": "preset", "id": "myGlow", "preset": "glow", "stdDeviation": 8, "color": "#ff00ff" }プリセット | 主要パラメータ | 効果 |
|
| 柔らかなハロー |
|
| 強烈な輝き |
|
| ガウスぼかし |
|
| ドロップシャドウ |
|
| 乱流変位（アニメーション） |
|
| 彩度を落とす |
| — | 温かみのあるセピア調 |
| — | 色を反転 |
|
| 彩度を強調/低減 |
|
| 色相をシフト |
|
| レンズ歪みのようなRGBチャンネルのズレ |
|
| フィルムグレインとテクスチャのオーバーレイ |
|
| 要素の周囲に色付きのアウトライン |
|
| 要素の内側に影 |
|
| 3Dレリーフの陰影効果 |
{
"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プロパティキー: camelCase (strokeDashoffset) または kebab-case (stroke-dashoffset)。どちらも機能します。
アニメーション可能なCSSプロパティ: opacity, fill, stroke, transform, filter, clip-path, stroke-dasharray, stroke-dashoffset, font-size, letter-spacingなど。
3つのSMILタイプ。各要素で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" }パスモーフィング (attributeName: "d"): from/toのパスは、コマンドの種類と数が同一である必要があります。座標のみが異なる必要があります。
システムフォントは読み込みなしでどこでも機能します: Arial, Helvetica, Courier New, Georgia, Verdana, monospace, sans-serif, serif。
カスタムフォントファミリーも受け入れられます。これらは、レンダリング環境（フォントが読み込まれたWebページ、デザインツールなど）でフォントが利用可能な場合に機能します。
コンテキスト | CSS @keyframes | SMIL | 外部フォント | インタラクティブ (onclick) |
GitHub README | ✅ | ✅ | ❌ | ❌ |
Webページ | ✅ | ✅ | ❌ | ❌ |
Webページ インラインSVG | ✅ | ✅ | ✅ | ✅ |
デザインツール書き出し | ✅ | ✅ | ✅ | — |
静的ファイルビューア | ✅ | ✅ | 環境依存 | 環境依存 |
これは、ハンドラーに到達する前にMCP SDKが入力を拒否したことを意味します。通常、最初の試行で発生し、再試行で成功します。最も一般的な原因：
グラデーションタイプのタイプミス。 "linear"や"radial"ではなく、"linearGradient"または"radialGradient"を使用してください。これが最も頻繁なミスです。
キーフレームオフセットが文字列。 0または100（数値）か、"from" / "to"と記述してください。"0%"や"100%"と書くと失敗します。
名前付きカラー。 16進数値のみが機能します: "#ff0000"。"red"は不可。rgb()も不可です。
要素のtypeの欠落。 すべての要素オブジェクトにはtypeフィールドが必要です。
MCPクライアント統合を構築していてこれが一貫して表示される場合、クライアントが引数をシリアライズする方法に問題がある可能性があります。既知のシリアライズの癖についてはanthropics/claude-code#29104を参照してください。
プレビューツールはt=0での静的スナップショットをレンダリングします。アニメーションはキャプチャされません。表示されるのは、CSSやSMILアニメーションが開始される前のSVGの初期状態です。
画像が完全に空白の場合：
要素にfillまたはstrokeが設定されているか確認してください。塗りつぶしのない形状は透明なキャンバス上では見えません。
座標を確認してください。800px幅のキャンバス上のx: 2000にある要素は、単に画面外にあります。
filter: "url(#myFilter)"を使用している場合、myFilterがdefs.filtersで実際に定義されていることを確認してください。
GitHubのREADMEは<img>タグを介してSVGをレンダリングしますが、これはJavaScriptを除去し、CSSとSMILを保持します。アニメーションがローカルで機能するのにGitHubで機能しない場合：
<script>やイベントハンドラー（onclick, onmouseover）は避けてください。これらは削除されます。
外部フォントは読み込まれません。システムフォント（Arial, Courier New, Georgia, monospace, sans-serif）を使用してください。
フォント用のCSS @importはブロックされます。特定のフォントが必要な場合は、システムフォントをフォールバックとして指定したインラインの<text>を使用してください。
render_svgがファイルサイズ（50kb以上）に関する警告を返す場合、パラメトリック曲線やパターン・グループが多すぎる要素を生成している可能性があります。パラメトリック曲線のstepsやパターン・グループのcountを減らしてください。cols: 50, rows: 50のgrid-groupは2500個の要素を生成し、すぐにサイズが大きくなります。
TypeScript + Node.js 18+
@modelcontextprotocol/sdk (MCPサーバー)
zod (スキーマ検証とAIタイプガイダンス)
外部SVGライブラリなし、純粋なXML構築
Vitest (280
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)
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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 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.
| Name | Required | Description | Default |
|---|---|---|---|
| defs | No | ||
| canvas | Yes | ||
| output | No | ||
| elements | Yes | ||
| animations | No |
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.
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.
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.
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.
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.
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.
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.
| 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. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0render_svg1 field changedInput schema / properties / output / properties / framesAdded value: +{
+ "type": "number"
+}v0.2.0preview3 fields changedInput schema / properties / artifactAdded value: +{
+ "description": "Artifact id returned by render_svg (e.g. \"art-1\"). Preferred over content.",
+ "type": "string"
+}Input schema / properties / content / descriptionPrevious value: -"SVG string to render as PNG"New value: +"SVG string to render as PNG. Only needed when no artifact id exists."Input schema / requiredRemoved value: -[
- "content"
-]render_svg6 fields changedInput schema / additionalPropertiesPrevious value: -falseNew value: +trueInput schema / properties / animations / items / additionalPropertiesPrevious value: -falseNew value: +trueInput schema / properties / animations / items / properties / keyframes / items / additionalPropertiesPrevious value: -falseNew value: +trueInput schema / properties / canvas / additionalPropertiesPrevious value: -falseNew value: +trueInput schema / properties / defs / additionalPropertiesPrevious value: -falseNew value: +trueInput schema / properties / outputAdded value: +{
+ "additionalProperties": true,
+ "properties": {
+ "minify": {
+ "type": "boolean"
+ },
+ "preview": {
+ "type": "boolean"
+ },
+ "previewWidth": {
+ "type": "number"
+ },
+ "svg": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}save3 fields changedInput schema / properties / artifactAdded value: +{
+ "description": "Artifact id returned by render_svg (e.g. \"art-1\"). Preferred over content.",
+ "type": "string"
+}Input schema / properties / content / descriptionPrevious 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."Input schema / requiredPrevious value: -[
- "content",
- "outputPath"
-]New value: +[
+ "outputPath"
+]v0.1.0render_svg2 fields changedInput schema / properties / animations / items / properties / keyframes / minItemsRemoved value: -2Input schema / properties / elements / minItemsRemoved value: -1v0.1.3previewrender_svgsaveScored across 3 tools
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.
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.
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.
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.
MCP server for Flux AI image generation
MCP server for Wan AI video generation
MCP server for Hailuo (MiniMax) AI video generation
Make animated videos by asking Claude, Cursor or any MCP client. Your AI writes it, we render it.