sketchbord-mcp

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

Сервер MCP, который позволяет ИИ-агенту визуализировать задачу на доске Sketchbord — и читать доску обратно, включая то, что нарисовал человек.

Смысл не в том, чтобы «нарисовать блок-схему». Агент описывает задачу как набор секций — систему, нарисованную в виде столбцов с подписанными стрелками между ними, чек-лист, интеллект-карту, воронку, диаграмму Исикавы, диаграмму последовательности, дорожную карту, стену стикеров, а иногда и поток — а сервер раскладывает их как постер, так что один взгляд объясняет задачу.

Одна картина, а не дерево страниц. Раньше доски обрастали уровнями детализации: блок с детьми становился отдельным уровнем, верхний уровень почти ничего не говорил, а часть, которая что-то объясняла, лежала на два клика вглубь, куда никто не смотрел. Секция lanes говорит об этом одним видом — части рядом, что каждая делает внутри, и что между ними передаётся, написано на стрелках.

Четыре вещи делают это чем-то большим, чем API для рисования:

• Содержание определяет структуру, а не тип задачи. Нет шаблона доски: pick_form сопоставляет форму того, что у вас есть — порядок, иерархию, сравнение, цикл, набор причин — с формой, которая это несёт, и говорит, когда каждая форма не подходит. Две доски для двух задач не должны выглядеть одинаково, а секция, повторяющая соседнюю, — это та, которую читатель вынужден перечитывать зря.

• Она рисует всей доской. Пиктограммы из собственного каталога доски (list_icons — нарисованные той же рукой, а не вставленные картинки), цвет для каждой части, стрелки, которые говорят, что по ним передаётся, и карточки, которые набрасывают экран, который они описывают (ui: поле поиска, кнопка, три строки списка). Картина, где каждый элемент — прямоугольник со словами, — это та, которую читателю приходится читать.

• Правки инкрементальны. visualize_task с mode: merge переписывает только те секции, которые вы назвали — всё остальное остаётся на месте, включая собственные стикеры и стрелки пользователя. read_board сообщает о таких добавлениях пользователя обратно (userMarks), так что агент может реагировать на то, что нарисовал человек, например, превращать это в изменения кода.

• Она читает рисунок обратно. Агент рисует вслепую: он никогда не узнаёт, что его картина вышла как четыре вложенных маркированных списка, что половина стрелок ничего не говорит, что подпись разрослась в предложение. Поэтому каждый рисунок отвечает тем, чем рисунок измеримо является — и ничем больше, потому что правило («на доске должно быть пять секций») — это форма, повторяемая независимо от задачи, из-за чего все доски становятся похожими. Замечания — это наблюдения, которые можно принять или проигнорировать для каждой задачи, а доска, в которой нет ничего достойного замечания, не получает замечаний вовсе.

Инструменты

Related MCP server: Overboard Studio MCP Server

Настройка

Вам нужен API-ключ (bord_sk_…) с sketchbord.ru:

• Ключ аккаунта (рекомендуется) — Мои доски → API-ключи → создайте ключ без выбора доски. Он может создавать доску для каждой задачи и рисовать на любой доске, которую вы можете редактировать.

• Ключ доски — та же страница с выбранной доской или внутри доски: меню (☰) → «Интеграции с ИИ». Привязан к одной доске, так что boardId никогда не нужен.

Настройка MCP-клиента

Сервер говорит по MCP через stdio. Ключ — это вся конфигурация: есть один размещённый Sketchbord, и сервер знает, где он находится.

Claude Code / Claude Desktop (.mcp.json или claude_desktop_config.json):

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

Из клона вместо этого:

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

Окружение

Два вида ключей

• Ключ аккаунта (без доски) — действует от имени вашего аккаунта, поэтому агент может создавать доску под каждую задачу (create_board или visualize_task с newBoard) и рисовать на любой доске, которую вы можете редактировать. Задайте BORD_BOARD_ID, если предпочитаете, чтобы по умолчанию использовался один проект.

• Ключ доски — привязан к одной доске, определяется по ключу.

Анатомия секции

У каждой секции есть стабильный id (именно он делает правки инкрементальными), kind, title, а затем те поля, которые использует её вид:

• items (note / tag / color / done / span / children) — списки, шаги, чек-листы, деревья, интеллект-карты, стикеры, карточки, таймлайны, метрики, полосы воронки (от широкой к узкой) или пирамиды (от вершины), шаги цикла, множества диаграммы Венна, категории причин диаграммы «рыбья кость»;

• groups — опоры постера lanes (id / subtitle / icon / color, а также bare для колонки людей по левому краю), колонки канбана, 4 квадранта, две стороны proscons (первая — за, вторая — против), дорожки roadmap;

• links — только для lanes: стрелки между опорами (from / to по id дорожки, позиции или заголовку, label для того, что по ней перемещается, both, dashed);

• nodes + edges — flow / states, а также sequence, где узел — участник, а ребро — сообщение;

• columns + rows — table; для roadmap columns — это периоды, а span каждого элемента называет те, которые перекрывает его полоса;

• text — абзац note, эффект в голове fishbone, подпись для пересечения venn.

Любая секция, элемент или группа может нести icon (id из list_icons; всё остальное отбрасывается, а не рисуется как заглушка). Карточка внутри секции lanes может нести ui вместо children — field / button / row / chip — что набрасывает интерфейс, который она описывает.

width — это narrow / normal / wide — подсказка о пропорции, кроме lanes, где она задаёт ширину одной опоры. accent в плане задаёт цвет доски, так что две доски не обязаны выглядеть одинаково.

Типы узлов блок-схемы: process (шаг), decision (ветвление — используйте подписанные рёбра), error (сбой), start/end (терминалы).

Стоимость в токенах

Определения инструментов, которые публикует этот сервер, занимают около 21 КБ (~6 000 токенов), и они находятся в контексте агента при каждом запросе. Большая часть — это схема visualize_task, что является ценой DSL, который агент может заполнить без лишнего круга запросов. Всё остальное намеренно тонкое: подробные указания о том, какую форму выбрать, живут в pick_form и sketch_board, которые ничего не стоят, пока их не вызовут, а read_board ограничивает свой ответ 60 000 символов, чтобы одна доска не могла заполнить окно контекста.

Чтение досок — это граница доверия

read_board возвращает текст, написанный другими людьми. Сервер оборачивает его в явные разделители «недоверенных данных» и ограничивает его размер, потому что этот контент попадает в модель в том же контексте, что и ваши инструкции — стикер с надписью «игнорируй предыдущие инструкции» — это попытка prompt-инъекции, и его следует читать как то, что пользователь написал на белой доске, а не как команду.

Примеры запросов

Объясни на доске, как устроен сервис: фронтенд, API, воркеры, Postgres и S3.

Секция lanes: опора на каждую часть, с карточкой для каждого её действия, иконкой на каждой карточке и links между опорами с подписями «HTTP request», «SQL», «file URL». Полоса process под ней, если сквозной путь стоит расписать, и полоса glossary, если читатель не из команды. ui на карточках фронтенда превращает «есть экран поиска» в картинку этого экрана.

Нарисуй задачу: импорт прайс-листа из CSV в каталог.

Фиксированного ответа нет. Агент спрашивает, что нужно знать читателю, и выбирает форму под каждую часть: потери строк на каждом шаге импорта — это funnel с числами в note; несколько несвязанных причин сбоя — fishbone; что трогать в коде — tree; что и в каком порядке происходит между CSV, парсером и каталогом — sequence. Затем checklist для работы — настоящие чекбоксы, которые отмечает тот, кто её выполняет.

Я нарисовал на доске стрелку и стикер — посмотри и исправь код.

read_board возвращает userMarks, например стикер «нужен повтор здесь!», лежащий на секции flow, и нарисованную от руки стрелку, соединяющую два блока. Агент действует по этому, затем отражает решение обратно через visualize_task (mode: merge) или операцию add_sticky — оставляя остальную часть доски нетронутой.

Замени план и убери легенду.

visualize_task с mode: merge и одной секцией plan, затем update_visual с removeSections: ["legend"]. Карточка plan перерисовывается на месте; всё остальное сохраняет свою позицию.

Разработка

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

Лицензия

MIT — см. LICENSE.