MCP для Revit: как AI-клиент управляет моделью

Что такое MCP и зачем он Revit

Model Context Protocol описывает, как AI-клиент узнаёт о возможностях внешнего приложения и вызывает их. Сервер публикует инструменты с описанием и схемой параметров; клиент передаёт модели этот список и получает от неё решение, какой инструмент вызвать с какими аргументами. Дальше сервер выполняет вызов и возвращает структурированный результат.

Без MCP агент видит только файлы проекта. Он может написать C#-код, но не может ответить на вопрос «сколько в модели помещений без имени» — для этого нужен доступ к живому документу. MCP превращает Revit из «приложения, о котором модель знает по документации» в источник фактов, к которому можно обратиться во время работы.

Важно, что MCP не даёт модели магических прав. Всё, что она может сделать, заранее описано инструментами. Если инструмента «удалить все стены» нет, модель не сможет его вызвать, сколько бы убедительно ни звучал запрос.

Как устроена связка в RevitAiTools

В проекте C#-плагин и MCP-сервер — одна система. Плагин загружается в Revit, регистрирует команды в ленте и одновременно поднимает локальный HTTP-сервер. Сервер описывает каталог инструментов, принимает вызовы по JSON-RPC и ставит их в очередь на исполнение в UI-потоке Revit.

• Контракт инструмента задаётся схемой: имя, назначение, параметры, формат результата.
• Транспорт — Streamable HTTP: клиент подключается к loopback-адресу и остаётся на связи.
• Исполнение — на потоке Revit через очередь задач, а не из сетевого потока напрямую.
• Изменения модели — в транзакциях; результат возвращается как данные, а не как «молчание».
• Каталог модульный: новый инструмент регистрируется манифестом, ядро не переписывается.

Такая схема убирает промежуточные звенья вроде named pipe и внешнего процесса-посредника. Меньше звеньев — меньше мест, где соединение рвётся и где непонятно, кто именно не ответил.

Путь одного запроса

1. Формулировка. Пользователь пишет: «найди воздуховоды без расхода и подсвети их красным».
2. Выбор инструмента. Клиент передаёт модели список инструментов; модель выбирает чтение и, если нужно, инструмент изменения.
3. Валидация. Сервер проверяет аргументы по схеме: типы, обязательные поля, допустимые значения. Неверный вызов отбивается до Revit.
4. Исполнение. Задача попадает в очередь UI-потока, открывается транзакция, выполняется выборка или изменение.
5. Результат. Клиент получает список Id, количества или текст ошибки — то, на что можно опереться в следующем шаге.

Каждый шаг наблюдаем. Если модель ошиблась с инструментом, это видно по вызову. Если инструмент отказал, это видно по ответу. «AI что-то сделал и не сказал» — признак плохо спроектированного контракта, а не неизбежность.

Контракт инструмента

Хороший инструмент отвечает на один вопрос и не прячет побочные эффекты. Пример схемы read-only инструмента:

{
  "name": "rooms.find_without_name",
  "description": "Возвращает помещения без параметра «Имя» на активном виде.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "levelName": { "type": "string", "description": "Ограничить уровнем" }
    },
    "additionalProperties": false
  }
}

В описании важно указать границы: активный вид или весь документ, только чтение или изменение, что означает пустой результат. Модель выбирает инструмент по описанию, и расплывчатое описание — главная причина неверных вызовов.

Для изменяющих инструментов полезно разделять «подготовить» и «применить». Первый возвращает план и количество затронутых элементов, второй выполняет его по идентификатору плана. Это добавляет шаг, на котором человек может остановить операцию.

Что можно попросить

Запрос формулируется обычным языком, а не командами интерфейса. Реалистичные примеры для инженера:

• «Покажи все помещения без номера и без имени, сгруппируй по уровню».
• «Найди воздуховоды без расхода и подсвети их красным».
• «Сверь марки дверей с типоразмерами и верни расхождения».
• «Собери ведомость помещений по уровням с площадями и отметь нулевые».
• «Проверь, что у всех стен есть огнестойкость, и покажи список исключений».

Общий признак хорошего запроса — проверяемый результат. «Сделай красиво» проверить нельзя; «верни список Id, где значение пустое» — можно.

Для записи формулировка должна включать границы: «только выбранные элементы», «только уровень 2», «не трогай типы». Ограничение сужает зону ошибки и делает откат понятным.

Безопасность: где на самом деле риск

Риск исходит не от «MCP как протокола», а от конкретных инструментов и от того, что модель может ошибиться в выборе. Поэтому защита строится на трёх уровнях.

• Сеть. Сервер слушает loopback. Порт не должен быть доступен из локальной сети; это локальный инструмент, а не сервис для коллег.
• Контракт. Read-only инструменты отделены от пишущих. Пишущий инструмент валидирует аргументы и работает в транзакции с откатом при ошибке.
• Процесс. Сначала план, потом применение. Эксперименты — на копии модели. Результат проверяется по отчёту, а не по фразе «готово».

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

Ограничения подхода

• MCP-сервер живёт столько же, сколько Revit. Закрыли приложение — инструменты недоступны, пока не запустите снова.
• Модель не «понимает» Revit сама по себе: качество зависит от описаний инструментов и от выбранной модели.
• Большие модели и тяжёлые выборки требуют пагинации и ограничений: один ответ не должен содержать сотни тысяч элементов.
• Транзакция защищает от частичного применения, но не от неверной логики. «Успешно записано неправильное значение» — всё ещё ошибка.
• Инструменты не заменяют проверку норм и ответственность инженера. Они ускоряют рутину и делают факты видимыми.

С какими клиентами работает

Сервер рассчитан на MCP-клиенты с HTTP-транспортом: Claude Code, Cursor, Kilo и другие совместимые клиенты. Настройка входит в первый шаг маршрута: к концу настройки модель вызывает инструменты на вашей модели, а не рассуждает о них.

Пошаговая инструкция для Claude Code — в материале «Claude Code и MCP для Revit». Если вы ещё не собирали плагин, начните с базового маршрута.

С чего начать

Разверните связку AI-клиента и MCP-сервера, затем повторите первый read-only запрос на тестовой модели. Убедитесь, что ответ совпадает с тем, что вы видите в Revit. Только после этого переходите к изменениям.

Дальше маршрут совпадает с разработкой плагина: задача, контекст, код и тесты, сборка и передача результата. Практические шаги и разборы входят в доступ к приватному репозиторию и курсу; условия и актуальная цена — на главной странице.