sketchbord-mcp

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

Ein MCP-Server, der es einem KI-Agenten ermöglicht, eine Aufgabe auf einem Sketchbord-Whiteboard zu visualisieren — und das Board zurückzulesen, einschließlich dessen, was der Mensch darauf gezeichnet hat.

Es geht nicht darum, „ein Flussdiagramm zu zeichnen“. Der Agent beschreibt eine Aufgabe als eine Handvoll Sektionen — ein System, das als Säulen mit beschrifteten Pfeilen dazwischen gezeichnet wird, eine Checkliste, eine Mindmap, ein Trichter, ein Fischgrätendiagramm, ein Sequenzdiagramm, eine Roadmap, eine Wand mit Haftnotizen und manchmal ein Ablauf — und der Server legt sie als Poster an, sodass ein Blick die Aufgabe erklärt.

Ein Bild, kein Baum von Seiten. Boards wuchsen früher zu Drill-down-Ebenen: Ein Block mit Kindern wurde zu einer eigenen Ebene, die oberste Ebene sagte fast nichts, und der Teil, der etwas erklärte, saß zwei Klicks tiefer, wo niemand hinschaute. Eine lanes-Sektion sagt es in einer Ansicht — die Teile nebeneinander, was jedes darin tut, und was zwischen ihnen reist, steht auf den Pfeilen.

Vier Dinge machen es mehr als eine Zeichen-API:

• Der Inhalt entscheidet über die Struktur, nicht die Art der Aufgabe. Es gibt keine Board-Vorlage: pick_form bildet die Form dessen, was du hast — eine Reihenfolge, eine Hierarchie, ein Vergleich, eine Schleife, eine Reihe von Ursachen — auf die Form ab, die es trägt, und sagt, wann jede Form die falsche ist. Zwei Boards für zwei Aufgaben sollten nicht gleich aussehen, und eine Sektion, die ihren Nachbarn wiederholt, ist eine, die der Leser zweimal lesen muss, ohne Grund.

• Es zeichnet mit dem ganzen Board. Piktogramme aus dem eigenen Katalog des Boards (list_icons — von derselben Hand gezeichnet, keine eingefügten Bilder), eine Farbe pro Teil, Pfeile, die sagen, was entlang ihnen reist, und Karten, die den Bildschirm skizzieren, den sie beschreiben (ui: ein Suchfeld, ein Button, drei Zeilen einer Liste). Ein Bild, in dem jedes Element ein Rechteck mit Wörtern ist, ist eines, das der Leser lesen muss.

• Bearbeitungen sind inkrementell. visualize_task mit mode: merge überschreibt nur die Sektionen, die du nennst — alles andere behält seinen Platz, einschließlich der eigenen Haftnotizen und Pfeile des Benutzers. read_board meldet diese Benutzerergänzungen zurück (userMarks), sodass der Agent auf das reagieren kann, was eine Person skizziert hat, z. B. es in Codeänderungen umwandeln.

• Es liest die Zeichnung zurück. Ein Agent zeichnet blind: Er erfährt nie, dass sein Bild als vier gestapelte Aufzählungslisten herauskam, dass die Hälfte der Pfeile nichts sagt, dass eine Bildunterschrift zu einem Satz anwuchs. Also antwortet jede Zeichnung mit dem, was die Zeichnung messbar ist — und sonst nichts, denn eine Regel („Boards sollten fünf Sektionen haben“) ist eine Form, die bei jeder Aufgabe wiederholt wird, und so endet jedes Board gleich. Bemerkungen sind Beobachtungen, die man pro Aufgabe akzeptieren oder ignorieren kann, und ein Board, bei dem es nichts Bemerkenswertes gibt, erhält überhaupt keine Bemerkungen.

Werkzeuge

Related MCP server: Excalidraw MCP Server

Einrichtung

Du benötigst einen API-Schlüssel (bord_sk_…) von sketchbord.ru:

• Kontoschlüssel (empfohlen) — Мои доски → API-ключи → erstelle einen Schlüssel, ohne ein Board auszuwählen. Er kann ein Board pro Aufgabe erstellen und auf jedem Board zeichnen, das du bearbeiten kannst.

• Board-Schlüssel — dieselbe Seite mit einem ausgewählten Board oder innerhalb eines Boards: Menü (☰) → «Интеграции с ИИ». An ein Board gebunden, daher ist boardId nie erforderlich.

MCP-Client konfigurieren

Der Server spricht MCP über stdio. Der Schlüssel ist die gesamte Konfiguration — es gibt ein gehostetes Sketchbord und der Server weiß, wo es ist.

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

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

Stattdessen aus einem Klon:

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

Umgebung

Zwei Arten von Schlüsseln

• Account-Schlüssel (kein Board) — handelt für dein Konto, sodass der Agent pro Aufgabe ein Board erstellen kann (create_board oder visualize_task mit newBoard) und auf jedem Board zeichnen kann, das du bearbeiten kannst. Setze BORD_BOARD_ID, wenn du lieber möchtest, dass es standardmäßig ein Projekt verwendet.

• Board-Schlüssel — an ein einzelnes Board gebunden, wird aus dem Schlüssel abgeleitet.

Anatomie eines Abschnitts

Jeder Abschnitt hat eine stabile id (das macht Bearbeitungen inkrementell), eine kind, einen title und dann die Felder, die seine Art verwendet:

• items (note / tag / color / done / span / children) — Listen, Schritte, Checklisten, Bäume, Mindmaps, Haftnotizen, Karten, Zeitachsen, Metriken, die Bänder eines Trichters (breiteste zuerst) oder einer Pyramide (Spitze zuerst), die Schritte eines Zyklus, die Mengen eines Venn-Diagramms, die Ursachenkategorien eines Fischgrätendiagramms;

• groups — die Säulen eines lanes-Posters (id / subtitle / icon / color und bare für die Spalte der Personen am linken Rand), Kanban-Spalten, die 4 Quadranten, die beiden Seiten von proscons (erste dafür, zweite dagegen), die Spuren einer roadmap;

• links — nur lanes: die Pfeile zwischen den Säulen (from / to nach Spur-ID, Position oder Titel, label für das, was entlang reist, both, dashed);

• nodes + edges — flow / states, und sequence, wobei ein Knoten ein Teilnehmer und eine Kante eine Nachricht ist;

• columns + rows — table; bei einer roadmap sind columns die Zeiträume und der span jedes Elements benennt die, die sein Balken abdeckt;

• text — der Absatz einer note, die Wirkung am Kopf eines fishbone, die Beschriftung für die Überlappung eines venn.

Jedes Element, jede Gruppe oder jeder Abschnitt kann ein icon tragen (eine ID aus list_icons; alles andere wird verworfen, statt als Platzhalter gezeichnet zu werden). Eine Karte in einem lanes-Abschnitt kann ui statt children tragen — field / button / row / chip —, was die beschriebene Oberfläche skizziert.

width ist narrow / normal / wide — ein Hinweis auf die Proportion, außer bei lanes, wo es die Breite einer Säule festlegt. accent im Plan setzt die Farbe des Boards, sodass zwei Boards nicht gleich aussehen müssen.

Flowchart-Knotentypen: process (Schritt), decision (Verzweigung — beschriftete Kanten verwenden), error (Fehler), start/end (Terminals).

Token-Kosten

Die Tool-Definitionen, die dieser Server veröffentlicht, sind etwa 21 KB (~6 000 Tokens) groß und liegen bei jeder Anfrage im Kontext des Agents. Der größte Teil davon ist das Schema von visualize_task, das ist der Preis einer DSL, die ein Agent ohne Roundtrip ausfüllen kann. Alles andere ist bewusst dünn gehalten: Die ausführliche Anleitung, welche Form du wählen sollst, steckt in pick_form und sketch_board, die nichts kosten, bis sie aufgerufen werden, und read_board begrenzt seine Antwort auf 60 000 Zeichen, sodass ein einzelnes Board kein Kontextfenster füllen kann.

Das Lesen von Boards ist eine Vertrauensgrenze

read_board gibt Text zurück, den andere geschrieben haben. Der Server umschließt ihn mit expliziten Begrenzern für "unvertrauenswürdige Daten" und begrenzt seine Größe, weil dieser Inhalt das Modell im selben Kontext wie deine Anweisungen erreicht — eine Haftnotiz mit "ignoriere vorherige Anweisungen" ist ein Prompt-Injection-Versuch und sollte als etwas gelesen werden, das ein Benutzer auf ein Whiteboard geschrieben hat, nicht als Befehl.

Beispiel-Prompts

Erkläre auf einem Board, wie der Dienst aufgebaut ist: Frontend, API, Worker, Postgres und S3.

Ein lanes-Abschnitt: eine Säule pro Teil, mit einer Karte für jede Sache, die es tut, einem Icon auf jeder Karte und links zwischen den Säulen, die "HTTP request", "SQL", "file URL" tragen. Ein process-Streifen darunter, wenn der End-to-End-Pfad es wert ist, ausformuliert zu werden, und ein glossary-Streifen, wenn der Leser nicht im Team ist. ui auf den Frontend-Karten verwandelt "es gibt einen Suchbildschirm" in ein Bild davon.

Zeichne die Aufgabe: Importieren einer Preisliste aus CSV in den Katalog.

Es gibt keine feste Antwort. Der Agent fragt, was der Leser wissen muss, und wählt pro Teil eine Form: Zeilen, die bei jedem Schritt des Imports verloren gehen, sind ein funnel mit den Zahlen in note; mehrere unzusammenhängende Fehlerursachen sind ein fishbone; was im Code angefasst werden muss, ist ein tree; was in welcher Reihenfolge zwischen CSV, Parser und Katalog passiert, ist eine sequence. Dann eine checklist für die Arbeit — echte Kontrollkästchen, die von demjenigen abgehakt werden, der sie ausführt.

Ich habe einen Pfeil und eine Haftnotiz auf das Board gezeichnet — schau nach und behebe den Code.

read_board gibt userMarks zurück, z. B. eine Haftnotiz "braucht hier einen Retry!", die auf dem flow-Abschnitt sitzt, und einen handgezeichneten Pfeil, der zwei Blöcke verbindet. Der Agent handelt danach und spiegelt die Entscheidung mit visualize_task (mode: merge) oder einer add_sticky-Operation zurück — der Rest des Boards bleibt unberührt.

Ersetze den Plan und entferne die Legende.

visualize_task mit mode: merge und einem plan-Abschnitt, dann update_visual mit removeSections: ["legend"]. Die plan-Karte wird an Ort und Stelle neu gezeichnet; alles andere behält seine Position.

Entwicklung

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

Lizenz

MIT — siehe LICENSE.