de en es ja ko ru zh

scuffed-painter

Name: scuffed-painter
Author: viktor-haag

by viktor-haag

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Scuffed Painter

Un servidor MCP (Model Context Protocol) que renderiza comandos de dibujo en imágenes rasterizadas usando Pillow. Expone dos herramientas:

draw_image — renderiza los comandos y devuelve el resultado como una imagen PNG en línea.
draw_image_to_file — renderiza los comandos y guarda el resultado en un archivo.

Se admiten cinco formas, cada una de ellas un objeto JSON discriminado por su campo "shape":

shape	parámetros
`line`	`start`, `end`, `color`, `width`
`rect`	`box` (izquierda, arriba, derecha, abajo), `fill`, `outline`, `width`
`circle`	`center`, `radius`, `fill`, `outline`, `width`
`ellipse`	`box` (x0, y0, x1, y1), `fill`, `outline`, `width`
`triangle`	`points` (exactamente tres vértices), `fill`, `outline`, `width`

Los comandos se ejecutan en el orden de la lista sobre un lienzo blanco de tamaño fijo; los comandos posteriores pintan sobre los anteriores. Los colores son nombres de color CSS o códigos hexadecimales.

Instalación

pip install .

Esto proporciona el script de consola scuffed-painter, que inicia el servidor MCP a través de stdio (el valor predeterminado). python -m scuffed_painter es una alternativa equivalente. El mismo comando también puede servir el servidor a través de HTTP (transporte MCP Streamable HTTP):

scuffed-painter                              # stdio transport (default)
scuffed-painter --transport http             # HTTP on 127.0.0.1:8000
scuffed-painter --transport http --host H --port P

--host y --port solo se aplican al transporte HTTP; los valores predeterminados son 127.0.0.1 y 8000. Puedes habilitar CORS con --enable-cors si es necesario.

Related MCP server: openai-imagegen-mcp

Configuración del host MCP

stdio

Añade el servidor a la configuración de servidores stdio de tu host MCP:

{
  "mcpServers": {
    "scuffed-painter": {
      "command": "scuffed-painter"
    }
  }
}

Nota: en un host con un PATH restringido o cuando se ejecute dentro de un virtualenv, usa la ruta absoluta al script scuffed-painter instalado en su lugar (por ejemplo, la que indica which scuffed-painter).

Streamable HTTP

Inicia el servidor tú mismo y luego apunta tu host MCP al endpoint (la ruta es /mcp):

scuffed-painter --transport http --host 127.0.0.1 --port 8000

{
  "mcpServers": {
    "scuffed-painter": {
      "type": "streamable-http",
      "url": "http://127.0.0.1:8000/mcp"
    }
  }
}

(Ajusta los nombres de las claves para que coincidan con el formato de configuración de tu host MCP).

Nota: cuando se usa draw_image_to_file, output_path se refiere a la máquina en la que se ejecuta el servidor. A través de stdio, esa máquina es el mismo host que el cliente MCP; cuando se accede al servidor a través de HTTP, es el host del servidor en su lugar.

Ejemplo de llamada a la herramienta

{
  "width": 200,
  "height": 200,
  "commands": [
    {"shape": "circle", "center": [100, 80], "radius": 50, "fill": "gold", "outline": "orange", "width": 3},
    {"shape": "triangle", "points": [[50, 170], [150, 170], [100, 70]], "fill": "darkgreen"},
    {"shape": "line", "start": [20, 185], "end": [180, 185], "color": "black", "width": 2}
  ]
}

Desarrollo

Estructura del repositorio:

scuffed_painter/          the package
  server.py             server, tools, command models, rendering
  __init__.py           re-exports mcp, defines __version__
  __main__.py           python -m scuffed_painter support
  py.typed              typing marker
tests/                  pytest suite (in-process fastmcp.Client)

Preparación y ejecución de las pruebas:

pip install -e ".[dev]"
python -m pytest

Available Tools

2 tools

draw_imageA

Draws a picture with pillow and returns the resulting image as inline PNG image content. This is especially usefull for (chat) applications that can directly display images.

width: canvas width in pixels (positive integer). height: canvas height in pixels (positive integer). commands: list of drawing commands, executed in order; each command is a JSON object with a "shape" field selecting one of: line, rect, circle, ellipse, triangle.

Supported shapes and their fields: line: "shape": "line", fields: start (x, y), end (x, y), color (default black), width (default 1) rect: "shape": "rect", fields: box (left, top, right, bottom), fill (default black, None for none), outline (default None), width (default 1) circle: "shape": "circle", fields: center (x, y), radius, fill (default black, None for none), outline (default None), width (default 1) ellipse: "shape": "ellipse", fields: box (x0, y0, x1, y1), fill (default black, None for none), outline (default None), width (default 1) triangle: "shape": "triangle", fields: points (three (x, y) vertices), fill (default black, None for none), outline (default None), width (default 1)

Commands are validated individually. Invalid commands are skipped, and a warning listing them (1-based positions) is included in the result; the image still contains all valid commands in order. If no command is valid, the call fails with a listing of the per-command errors.

Coordinate system: The coordinate system has its origin at the top-left corner; x increases to the right, y increases downward. All coordinates are in pixels on a fixed-size white background canvas; drawing outside the canvas bounds is clipped (harmless). Commands run in list order, and later commands overpaint earlier ones.

Color format: Color as a CSS color name (e.g. 'red', 'darkorange') or hex code (e.g. '#8b4513'). Values are passed through to Pillow.

Paint semantics: fill=None gives an unfilled shape; outline draws the border; width is the stroke width in pixels for line/rect/circle/ellipse/triangle.

Example (200x200 canvas): { "width": 200, "height": 200, "commands": [ {"shape": "circle", "center": [100, 80], "radius": 50, "fill": "gold", "outline": "orange", "width": 3}, {"shape": "triangle", "points": [[50, 170], [150, 170], [100, 70]], "fill": "darkgreen"}, {"shape": "line", "start": [20, 185], "end": [180, 185], "color": "black", "width": 2} ] }

Name	Required	Description	Default
`width`	Yes
`height`	Yes
`commands`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden, and it delivers thoroughly. It discloses invalid-command skipping with warnings, total-invalid-command failure behavior, coordinate origin and direction, clipping, overpainting order, color formats, and pass-through to Pillow. This is far beyond what annotations alone would provide.

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?

Although the description is long, the complexity of the tool justifies the length. It is well-structured with clear sections for shapes, coordinate system, colors, paint semantics, and an example, and the core purpose is front-loaded in the first sentence.

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 no annotations, no output schema, and a highly complex nested command format, the description covers everything an agent needs: complete shape schemas, defaults, validation behavior, failure modes, coordinate system details, and a full example. Nothing essential is missing.

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%, but the description fully compensates by explaining width, height, and commands in depth. It documents every supported shape, all their fields, defaults, color formats, coordinate semantics, and provides a working example, so no parameter meaning is left to inference.

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 opens with a specific verb and resource: 'Draws a picture with pillow and returns the resulting image as inline PNG image content.' This clearly differentiates the tool from its sibling draw_image_to_file by emphasizing inline PNG output rather than file output, so an agent can select it correctly.

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 gives clear context for when to use this tool: 'especially useful for (chat) applications that can directly display images.' It does not explicitly name draw_image_to_file as the alternative for file output, but the inline-image framing strongly implies that distinction, leaving little ambiguity.

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

draw_image_to_fileA

Draws a picture with pillow and saves the resulting image to a file.

output_path: absolute file path to save to; the image format is inferred from the extension (e.g. .png, .jpg). Parent directories are NOT created. width: canvas width in pixels (positive integer). height: canvas height in pixels (positive integer). commands: list of drawing commands, executed in order; each command is a JSON object with a "shape" field selecting one of: line, rect, circle, ellipse, triangle.

Color format: Color as a CSS color name (e.g. 'red', 'darkorange') or hex code (e.g. '#8b4513'). Values are passed through to Pillow.

Paint semantics: fill=None gives an unfilled shape; outline draws the border; width is the stroke width in pixels for line/rect/circle/ellipse/triangle.

Example (200x200 canvas): { "output_path": "/home/myuser/documents/picture.png", "width": 200, "height": 200, "commands": [ {"shape": "circle", "center": [100, 80], "radius": 50, "fill": "gold", "outline": "orange", "width": 3}, {"shape": "triangle", "points": [[50, 170], [150, 170], [100, 70]], "fill": "darkgreen"}, {"shape": "line", "start": [20, 185], "end": [180, 185], "color": "black", "width": 2} ] }

Name	Required	Description	Default
`width`	Yes
`height`	Yes
`commands`	Yes
`output_path`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses that parent directories are not created, invalid commands are skipped with warnings, no-valid-command fails, later commands overpaint earlier ones, drawing outside the canvas is clipped, and colors follow specific formats.

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 long, but the length is justified by the tool's complexity and the absence of schema-level documentation. It is front-loaded with a one-sentence purpose, then organized into clear labeled sections with a concrete example.

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 four required parameters, a free-form commands array, and no annotations, the description covers nearly every decision an agent needs to make: file path rules, canvas size, command shapes, validation behavior, coordinate system, painting order, and colors. The presence of an output schema means return-value details are not required.

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?

The input schema provides only names and basic types, so schema coverage is effectively 0%. The description compensates completely by explaining output_path semantics, width/height meaning, command structure, all supported shape fields, defaults, and coordinate/color conventions.

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 opens with a specific verb-resource pair: it draws a picture and saves it to a file. It also distinguishes itself from the sibling draw_image by emphasizing file output, so an agent can tell the tools apart.

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

Usage Guidelines3/5

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

The saving-to-file behavior implies when this tool is appropriate, but the description never explicitly states when to use it versus draw_image or what conditions would favor one over the other. This is usable but implied rather than explicit.

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.

2 tool updatesv0.1.0Aug 27, 2026
- First observeddraw_image
- First observeddraw_image_to_file

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.6/5.0

Scored 2026-08-27 12:20 across 2 tools

Disambiguation5/5

The two tools split cleanly by output destination: draw_image_to_file persists to disk, while draw_image returns inline PNG content. Their names and the presence of output_path only in the file variant make misselection unlikely.

Naming Consistency5/5

Both tools follow the same draw_image verb-object prefix, with the file-save variant adding the clear _to_file suffix. The naming is snake_case and consistent across the whole set.

Tool Count4/5

Two tools is slightly below the typical 3-15 range, but the count is reasonable for a narrow painter: one output mode is file saving and the other is inline PNG. It feels minimal rather than excessive.

Completeness4/5

The core draw-and-output workflow is fully covered: all five shapes, validation, coordinate handling, and both file and inline delivery are present. Minor gaps remain, such as only having a fixed white background and no text or image-import tools, though these are workaround-able or outside the narrow scope.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Related MCP Connectors

PencilOAuth
au.com.vyndigital
Lets AI assistants draw: logos, posters, illustrations and scenes, as editable SVG and PNG.
1
https://api.vyndigital.com.au/mcp
SVG AIOAuth
org.svgai
Generate and vectorize clean, editable SVG graphics from text, images, or both.
AI & Machine Learning Image & Video Processing Design Tools
1
https://www.svgai.org/api/mcp
Chart Generator & PDF Report from Any Dataset, CSV or JSONOAuth
io.github.Nero-Engine
Turn rows into bar, line, pie and scatter chart images plus an optional PDF or HTML report.
Data Visualization
1
https://mcp.apify.com/?tools=nerolabs/dataset-charts-report
KlyaksaOAuth
app.klyaksa
Online whiteboard your AI agent draws on: live shared canvases, solo or with your team.
Design Tools Workplace & Productivity
1
https://mcp.klyaksa.app/mcp

Related MCP Servers

Excalidraw MCP Server
Developer Tools File Systems Image & Video Processing
andreswebs-public-images
A
license
A
quality
D
maintenance
Enables creation, management, and export of Excalidraw drawings through natural language. Supports CRUD operations on drawings and export to SVG, PNG, and JSON formats with file-based storage.
Updated a year ago (2025-11-24 18:46 UTC)
8
8
2,461 npm
-
openai-imagegen-mcp
Image & Video Processing AI & Machine Learning
marabian
F
license
Not graded
quality
D
maintenance
Enables image generation and editing via OpenAI's gpt-image-1 model, with options for saving, format control, and transparency.
Updated a year ago (2025-08-12 04:23 UTC)
-
scribbleviz-mcp
Data Visualization Image & Video Processing
cadeos
A
license
Not graded
quality
C
maintenance
Enables LLM clients to create hand-drawn study-notes style graphics, including charts, concept maps, mind maps, timelines, sketch notes, and 2×2 matrices, as PNG images via MCP.
Updated a month ago (2026-09-16 14:17 UTC)
1
MIT
Napkin
Design Tools
enkind
A
license
Not graded
quality
B
maintenance
Enables agents to present an interactive drawing canvas to users, allowing them to sketch and send drawings back into the conversation as images.
Updated 25 days ago (2026-10-03 15:08 UTC)
4 npm
MIT

Scuffed Painter

Instalación

Configuración del host MCP

stdio

Streamable HTTP

Ejemplo de llamada a la herramienta

Desarrollo

Available Tools

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Excalidraw MCP Server

openai-imagegen-mcp

scribbleviz-mcp

Napkin