Microsoft Paint MCP Server for Node.js

Interfaz semántica MCP para Microsoft Paint que utiliza UI Automation, Win32 y un DSL de dibujo.

Documentación

Microsoft Paint MCP Server for Node.js

Inglés · Español

¿Y si Paint fuera más que Paint?

Microsoft Paint es probablemente uno de los programas menos intimidantes que jamás se hayan incluido con Windows.

Un lienzo en blanco. Un lápiz. Algunas formas. Una paleta de colores.

Para millones de personas, pudo haber sido uno de los primeros lugares donde una computadora se convirtió en algo con lo que podías experimentar en lugar de simplemente operar.

Esa simplicidad me despertó curiosidad.

No porque Paint necesitara automatización.

Sino porque quería entender una pregunta más interesante:

¿Hasta dónde puede llegar un software ordinario cuando se le da a una IA una forma significativa de entenderlo e interactuar con él?

Esa pregunta se convirtió en este proyecto.


Comenzó como un pequeño experimento

La forma obvia de automatizar Paint habría sido mover un mouse a coordenadas de pantalla conocidas y hacer clic en botones.

Eso funciona.

Pero no entiende nada.

Cambia la posición de la ventana, la escala de visualización, la disposición de la barra de herramientas o el entorno, y la automatización basada en coordenadas revela rápidamente lo que realmente es: un guion que reproduce gestos.

Quería abordar el problema de manera diferente.

Antes de enseñar a una IA a dibujar con Paint, quería entender el propio Paint.

Sus ventanas.

Sus controles.

Su lienzo.

Sus sistemas de coordenadas.

Su árbol de accesibilidad.

Su comportamiento.

Así que el experimento descendió antes de ascender.

En lugar de preguntar:

¿Cómo puede una IA hacer clic en Paint?

Empecé a preguntar:

¿Qué expone Paint sobre sí mismo que el software pueda entender realmente?

Eso me llevó a Windows UI Automation, la inspección del árbol de accesibilidad de Paint, el descubrimiento del lienzo, la gestión del ciclo de vida de las ventanas, las transformaciones de coordenadas, la entrada Win32 y, finalmente, una interfaz semántica entre una IA y la aplicación.

La curiosidad se convirtió en investigación.

La investigación se convirtió en estructura.

Y la estructura eventualmente se convirtió en un servidor MCP.


Paint se convirtió en el renderizador, no en la idea

Una vez que existió la capa de interacción, apareció otra pregunta.

Si una IA ya no tenía que pensar principalmente en coordenadas de mouse, ¿en qué debería pensar?

La respuesta no fue:

move pointer to x=412, y=287
press mouse button
move pointer to x=650, y=410
release

Fue algo más cercano a:

{
  "kind": "circle",
  "cx": 300,
  "cy": 220,
  "radius": 120
}

O:

{
  "solid": "tesseract",
  "size": 110,
  "projection": "perspective"
}

Esa distinción cambió el proyecto.

Paint ya no era la abstracción.

Se convirtió en la superficie de renderizado debajo de un lenguaje visual emergente.

El servidor MCP traduce descripciones semánticas y matemáticas en geometría, la geometría en coordenadas lógicas del lienzo, y esas coordenadas en interacción real con el mouse sobre Microsoft Paint.

Idea
  ↓
Semantic description
  ↓
Geometry
  ↓
Canvas coordinates
  ↓
Windows interaction
  ↓
Microsoft Paint

Esa es la parte del experimento que encuentro más interesante.


De círculos a un teseracto

La capa de dibujo gradualmente se convirtió en un pequeño DSL matemático.

Actualmente puede expresar cosas como:

  • círculos, elipses y arcos;
  • rectángulos y rectángulos redondeados;
  • polígonos regulares y estrellados;
  • espirales logarítmicas;
  • cuadrículas y estructuras repetidas;
  • polilíneas arbitrarias;
  • sólidos platónicos;
  • toros y nudos toroidales;
  • superficies de revolución;
  • mallas de alambre personalizadas;
  • e incluso un teseracto proyectado de 4D → 3D → 2D.

Las formas no se crean mediante los botones nativos de Formas de Paint.

Se generan matemáticamente como puntos y trazos y luego se dibujan físicamente sobre el lienzo.

Esa restricción es intencional.

Mantiene el experimento enfocado en el límite entre descripción abstracta e interacción real con la aplicación.


¿Por qué hacer esto con Paint?

Porque Paint es deliberadamente ordinario.

Si este experimento hubiera comenzado con Blender, AutoCAD, Mathematica u otro entorno visual sofisticado, gran parte de la capacidad podría atribuirse a la propia aplicación.

Paint no nos da casi nada.

Y eso lo hace útil.

Obliga a que la inteligencia y la abstracción vivan en otro lugar.

El resultado es un sandbox visual sorprendentemente flexible.

Una IA podría potencialmente usar el mismo lienzo primitivo para explicar:

Geometría

Construir polígonos, transformaciones, proyecciones y relaciones geométricas.

Matemáticas

Convertir ecuaciones y estructuras matemáticas en objetos visibles.

Razonamiento espacial

Explorar objetos tridimensionales a través de proyecciones bidimensionales.

Diagramas

Expresar flujos, relaciones, líneas de tiempo, mapas y modelos conceptuales simples.

Educación

Construir explicaciones visuales paso a paso usando una de las aplicaciones más simples disponibles en Windows.

La pregunta interesante ya no es, por lo tanto:

¿Puede una IA dibujar en Paint?

Claramente, puede.

La pregunta más útil es:

¿Qué puede explicar una IA cuando el dibujo se convierte en parte de su lenguaje?


Un ejemplo: un objeto de cuatro dimensiones en Paint

Uno de los generadores disponibles es un teseracto.

Un teseracto es el análogo de cuatro dimensiones de un cubo.

La implementación comienza con los dieciséis vértices del hipercubo, los proyecta de cuatro dimensiones a tres, proyecta el resultado nuevamente a dos dimensiones y finalmente convierte sus treinta y dos aristas en trazos que Paint puede dibujar físicamente.

Desde la perspectiva del cliente MCP, la solicitud sigue siendo semántica:

{
  "mode": "generator",
  "tool": "pencil",
  "fit": "contain",
  "generators": [
    {
      "kind": "solid",
      "solid": "tesseract",
      "size": 110,
      "rotX": 15,
      "rotY": -30,
      "projection": "perspective"
    }
  ]
}

Paint no sabe nada sobre geometría de cuatro dimensiones.

No necesita saberlo.

Es simplemente la superficie final donde una idea abstracta se vuelve visible.

Esa separación es la arquitectura.


No es automatización ciega

Se usó IA extensamente mientras se construía este proyecto.

Pero usar IA nunca fue la parte interesante.

La parte interesante fue decidir qué tenía que entenderse antes de que algo debiera automatizarse.

A lo largo del experimento, el flujo de trabajo se repitió de esta manera:

observe
  ↓
question
  ↓
inspect
  ↓
model
  ↓
experiment
  ↓
specify
  ↓
implement
  ↓
verify

Por ejemplo, el servidor no asume que el lienzo de Paint vive en una coordenada de pantalla permanente.

Descubre y resuelve el contexto de la aplicación, mantiene la sesión de Paint, mapea las coordenadas de dibujo lógicas al lienzo dibujable real y usa APIs de Windows para ejecutar la interacción.

Los resultados del dibujo también pueden verificarse después de la ejecución en lugar de asumir que la ausencia de una excepción significa que la tinta realmente apareció.

El objetivo no es ocultar la IA del proceso de ingeniería.

Tampoco es celebrar a la IA por producir código.

El experimento trata sobre otra cosa:

usar la IA para explorar un sistema más profundamente mientras se mantienen explícitos la comprensión, la arquitectura y la verificación.


Cómo funciona

A alto nivel:

LLM / MCP Client
        │
        ▼
     MCP Server
        │
        ▼
 PaintController
        │
        ├── Paint session management
        ├── UI Automation discovery
        ├── Semantic canvas resolution
        ├── Mathematical generators
        └── Coordinate transformation
        │
        ▼
 Win32 / SendInput adapter
        │
        ▼
 Microsoft Paint

El código sigue una estructura en capas / hexagonal que mantiene el dominio matemático independiente de la automatización específica de Windows.

La capa de geometría pura no sabe nada sobre Paint.

La capa de orquestación de Paint no sabe nada sobre clientes MCP.

La infraestructura de Windows implementa la mecánica necesaria para que la interacción final sea real.

Para la arquitectura técnica más profunda, consulta la documentación a continuación.


Capacidades MCP

El servidor actualmente expone siete herramientas MCP.

HerramientaPropósito
paint_drawDSL de dibujo 2D a mano alzada y matemático
paint_draw_3dProyectar y dibujar geometría de alambre 3D/4D
paint_napkinPrimitivas simples de pensamiento visual
paint_editOperaciones de borrar, rellenar, texto y recortar
paint_canvasRedimensionar y gestionar el lienzo
paint_debug_uiInspeccionar el árbol de UI Automation de Paint
paint_debug_canvasInspeccionar la geometría resuelta del lienzo

Las APIs de dibujo productivas operan en el espacio de dibujo lógico en lugar de requerir que quien llama sepa dónde está Paint en la pantalla.


La capa de dibujo semántico

El DSL 2D actualmente incluye generadores como:

ellipse
circle
disk
arc
rectangle
roundedRectangle
polyline
logarithmicSpiral
regularPolygon
starPolygon
grid
dotsAlongPath

La capa 3D incluye:

tetrahedron
cube
octahedron
dodecahedron
icosahedron
greatIcosahedron
starOctangula
tesseract
torus
torusKnot
revolution
wireframe

Estas descripciones se validan antes de llegar a la capa de dibujo y se transforman en geometría pura antes de que ocurra cualquier interacción con Windows.

La referencia completa del DSL se encuentra en:

docs/dsl-paint-draw.md


Bajo el capó: entendiendo Paint

El proyecto usa Windows UI Automation para descubrir los controles de la aplicación en lugar de depender completamente de coordenadas fijas de la barra de herramientas.

Esa investigación se volvió lo suficientemente útil como para documentarla de forma independiente.

Si te interesa entender cómo se puede inspeccionar y automatizar una aplicación moderna de Windows a través de su modelo de accesibilidad, consulta:

docs/windows-automation-uia.md

También hay un recorrido práctico con PowerShell:

docs/tutorial-paint-powershell.md

Estos documentos preservan la investigación de ingeniería detrás de la implementación MCP en lugar de ocultarla detrás de la API final.


Inicio rápido

Requisitos

  • Windows
  • Microsoft Paint
  • Node.js
  • PowerShell
  • un cliente compatible con MCP

Clona el repositorio:

git clone https://github.com/miguelcespedes/mcp-server-microsoft-paint-nodejs.git
cd mcp-server-microsoft-paint-nodejs

Instala las dependencias:

npm install

Compila:

npm run build

Ejecuta el servidor MCP:

npm start

Consulta .mcp.json para ver un ejemplo de configuración MCP.


Un pequeño experimento que vale la pena preservar

Este repositorio no es intencionalmente un intento de convertir Microsoft Paint en software de gráficos profesional.

Ya existen herramientas mucho mejores para eso.

Paint es útil aquí precisamente por sus limitaciones.

Proporciona un entorno familiar y restringido en el que varias preguntas se vuelven más fáciles de ver:

¿Cómo debería una IA describir una idea visual?

¿Dónde deberían terminar la semántica y comenzar la automatización específica de la aplicación?

¿Cuánta comprensión de la aplicación es necesaria antes de que la automatización se vuelva confiable?

¿Puede un lienzo simple convertirse en una interfaz útil para el razonamiento matemático o educativo?

¿Y qué sucede cuando dejamos de tratar el software antiguo solo según el propósito para el que fue diseñado originalmente?

No sé a dónde llevan todas esas preguntas.

Eso es parte de por qué existe este repositorio.


Documentación

DocumentoPropósito
docs/dsl-paint-draw.mdReferencia del DSL de dibujo matemático y generadores
docs/windows-automation-uia.mdInvestigación de Paint a través de Windows UI Automation
docs/tutorial-paint-powershell.mdTutorial práctico de automatización de Paint usando PowerShell

Arquitectura adicional, ejemplos, notas de prueba y detalles de implementación pueden moverse gradualmente aquí a medida que el experimento evolucione.


Estado

Este es un proyecto experimental.

Algunas capacidades son intencionalmente exploratorias y algunas partes de la interfaz de Microsoft Paint siguen siendo menos deterministas que otras.

Eso no se oculta.

Las limitaciones son parte de la investigación.

Si encuentras un caso límite, una mejor abstracción semántica, un generador matemático interesante, o simplemente otro uso inesperado para el lienzo, las contribuciones y los experimentos son bienvenidos.


Un último pensamiento

La curiosidad es buena para abrir puertas.

La disciplina es lo que evita que lo que encontramos desaparezca.

Y una vez que un descubrimiento se preserva, alguien más puede usarlo para comenzar otra exploración.

Quizás así es como la curiosidad se vuelve acumulativa.


Licencia

Este proyecto se publica bajo la Licencia MIT, Copyright (c) 2026 Miguel Cespedes.

Eres libre de usar, copiar, modificar, fusionar, publicar, distribuir, sublicenciar y/o vender copias del software, siempre que se conserve el aviso de copyright y permiso.