sketchbord-mcp

Русская версия

Un servidor MCP que permite a un agente de IA visualizar una tarea en una pizarra Sketchbord — y leer la pizarra de vuelta, incluyendo lo que el humano dibujó en ella.

El punto no es "dibujar un diagrama de flujo". El agente describe una tarea como un puñado de secciones — un sistema dibujado como pilares con flechas etiquetadas entre ellos, una lista de verificación, un mapa mental, un embudo, un diagrama de espina de pescado, un diagrama de secuencia, una hoja de ruta, una pared de notas adhesivas, y a veces un flujo — y el servidor las dispone como un póster, de modo que una mirada explica la tarea.

Una imagen, no un árbol de páginas. Las pizarras solían crecer en niveles de profundidad: un bloque con hijos se convertía en un nivel propio, el nivel superior no decía casi nada, y la parte que explicaba algo estaba a dos clics de distancia donde nadie miraba. Una sección lanes lo dice en una sola vista — las partes lado a lado, qué hace cada una dentro, y qué viaja entre ellas escrito en las flechas.

Cuatro cosas lo hacen más que una API de dibujo:

• El contenido decide la estructura, no el tipo de tarea. No hay plantilla de pizarra: pick_form mapea la forma de lo que tienes — un orden, una jerarquía, una comparación, un bucle, un conjunto de causas — sobre la forma que lo lleva, y dice cuándo cada forma es la incorrecta. Dos pizarras para dos tareas no deberían parecerse, y una sección que repite a su vecina es una que el lector tiene que leer dos veces para nada.

• Dibuja con toda la pizarra. Pictogramas del propio catálogo de la pizarra (list_icons — dibujados por la misma mano, no imágenes pegadas), un color por parte, flechas que dicen qué viaja a lo largo de ellas, y tarjetas que esbozan la pantalla que describen (ui: un campo de búsqueda, un botón, tres filas de una lista). Una imagen donde cada elemento es un rectángulo con palabras es una que el lector tiene que leer.

• Las ediciones son incrementales. visualize_task con mode: merge reescribe solo las secciones que nombras — todo lo demás mantiene su lugar, incluyendo las notas adhesivas y flechas propias del usuario. read_board informa de esas adiciones del usuario (userMarks), para que el agente pueda reaccionar a lo que una persona esbozó, p. ej. convertirlo en cambios de código.

• Te lee el dibujo de vuelta. Un agente dibuja a ciegas: nunca se entera de que su imagen resultó ser cuatro listas de viñetas apiladas, que la mitad de las flechas no dicen nada, que un título creció hasta convertirse en una frase. Así que cada dibujo responde con lo que el dibujo mediblemente es — y nada más, porque una regla ("las pizarras deberían tener cinco secciones") es una forma repetida sea cual sea la tarea, que es como todas las pizarras terminan pareciéndose. Las observaciones son observaciones para aceptar o ignorar según la tarea, y una pizarra sin nada digno de comentar no recibe comentarios en absoluto.

Tools

Related MCP server: Excalidraw MCP Server

Setup

Necesitas una clave API (bord_sk_…) de sketchbord.ru:

• Clave de cuenta (recomendada) — Мои доски → API-ключи → crea una clave sin elegir una pizarra. Puede crear una pizarra por tarea y dibujar en cualquier pizarra que puedas editar.

• Clave de pizarra — la misma página con una pizarra seleccionada, o dentro de una pizarra: menú (☰) → «Интеграции с ИИ». Vinculada a una sola pizarra, por lo que boardId nunca es necesario.

Configure your MCP client

El servidor habla MCP sobre stdio. La clave es toda la configuración — hay un Sketchbord alojado y el servidor sabe dónde está.

Claude Code / Claude Desktop (.mcp.json o claude_desktop_config.json):

{
  "mcpServers": {
    "sketchbord": {
      "command": "npx",
      "args": ["-y", "sketchbord-mcp"],
      "env": {
        "BORD_API_KEY": "bord_sk_xxx"
      }
    }
  }
}

Desde un clon en su lugar:

npm install
npm run build
# then "command": "node", "args": ["/path/to/sketchbord-mcp/dist/index.js"]

Environment

Dos tipos de clave

• Clave de cuenta (sin tablero) — actúa en nombre de tu cuenta, para que el agente pueda crear un tablero por tarea (create_board, o visualize_task con newBoard) y dibujar en cualquier tablero que puedas editar. Configura BORD_BOARD_ID si prefieres que use un proyecto por defecto.

• Clave de tablero — vinculada a un único tablero, se deduce de la clave.

Anatomía de una sección

Cada sección tiene un id estable (eso es lo que hace que las ediciones sean incrementales), un kind, un title y luego los campos que use su tipo:

• items (note / tag / color / done / span / children) — listas, pasos, listas de verificación, árboles, mapas mentales, notas adhesivas, tarjetas, cronologías, métricas, las bandas de un embudo (de más ancha a más estrecha) o de una pirámide (de la cúspide hacia abajo), los pasos de un ciclo, los conjuntos de un venn, las categorías de causa de un fishbone;

• groups — los pilares de un póster lanes (id / subtitle / icon / color, y bare para la columna de personas del borde izquierdo), columnas kanban, los 4 cuadrantes, los dos lados de proscons (el primero a favor, el segundo en contra), los carriles de un roadmap;

• links — solo lanes: las flechas entre pilares (from / to por id de carril, posición o título, label para lo que viaja por él, both, dashed);

• nodes + edges — flujo / estados, y sequence, donde un nodo es un participante y una arista es un mensaje;

• columns + rows — table; para un roadmap, columns son los periodos y el span de cada elemento nombra los que cubre su barra;

• text — el párrafo de una note, el efecto a la cabeza de un fishbone, la leyenda para la intersección de un venn.

Cualquier elemento, grupo o sección puede llevar un icon (un id de list_icons; cualquier otra cosa se descarta en lugar de dibujarse como marcador de posición). Una tarjeta dentro de una sección lanes puede llevar ui en lugar de children — field / button / row / chip —, que esboza la interfaz que describe.

width es narrow / normal / wide — una pista sobre la proporción, excepto en lanes, donde fija el ancho de un pilar. accent en el plan establece el color del tablero, para que dos tableros no tengan por qué parecerse.

Tipos de nodo de diagrama de flujo: process (paso), decision (bifurcación — usa aristas etiquetadas), error (fallo), start/end (terminales).

Coste de tokens

Las definiciones de herramientas que publica este servidor ocupan unos 21 KB (~6 000 tokens) y están en el contexto del agente en cada solicitud. La mayor parte es el esquema de visualize_task, que es el precio de un DSL que un agente puede rellenar sin una ida y vuelta. Todo lo demás es deliberadamente ligero: la guía extensa sobre qué forma elegir vive en pick_form y sketch_board, que no cuestan nada hasta que se llaman, y read_board limita su respuesta a 60 000 caracteres para que un tablero no pueda llenar una ventana de contexto.

Leer tableros es un límite de confianza

read_board devuelve texto que otras personas escribieron. El servidor lo envuelve en delimitadores explícitos de "datos no confiables" y limita su tamaño, porque ese contenido llega al modelo en el mismo contexto que tus instrucciones — una nota adhesiva que diga "ignora las instrucciones anteriores" es un intento de inyección de prompt, y debe leerse como algo que un usuario escribió en una pizarra, no como un comando.

Ejemplos de prompts

Explica en un tablero cómo está montado el servicio: front end, API, workers, Postgres y S3.

Una sección lanes: un pilar por parte, con una tarjeta por cada cosa que hace, un icono en cada tarjeta y links entre los pilares que llevan "petición HTTP", "SQL", "URL de archivo". Una tira process debajo si merece la pena detallar el recorrido de extremo a extremo, y una tira glossary si quien lee no es del equipo. ui en las tarjetas del front end convierte "hay una pantalla de búsqueda" en una imagen de una.

Dibuja la tarea: importar una lista de precios desde CSV al catálogo.

No hay una respuesta fija. El agente pregunta qué necesita saber quien lee y elige una forma por parte: las filas perdidas en cada paso de la importación son un funnel con los números en note; varias causas de fallo no relacionadas son un fishbone; qué tocar en el código es un tree; qué ocurre y en qué orden entre CSV, parser y catálogo es un sequence. Luego un checklist para el trabajo — casillas reales, marcadas por quien lo haga.

Dibujé una flecha y una nota adhesiva en el tablero — mira y arregla el código.

read_board devuelve userMarks, p. ej. una nota adhesiva "¡necesita un reintento aquí!" sobre la sección flow y una flecha dibujada a mano que conecta dos bloques. El agente actúa sobre eso y luego refleja la decisión con visualize_task (mode: merge) o una operación add_sticky — dejando el resto del tablero intacto.

Sustituye el plan y elimina la leyenda.

visualize_task con mode: merge y una sección plan, luego update_visual con removeSections: ["legend"]. La tarjeta plan se redibuja en su sitio; todo lo demás conserva su posición.

Desarrollo

npm install
npm run build      # tsc → dist/
npm run typecheck
BORD_API_KEY=bord_sk_… BORD_API_URL=http://localhost:4000 npm start

Licencia

MIT — consulta LICENSE.