EDT MCP — это подключаемый к 1С:EDT серверный модуль, через который агент читает конфигурацию проекта, предлагает правку модуля и запускает проверку, а результат уходит разработчику на review. В проверенных нами источниках официального сервера от 1С нет: в открытом доступе лежат проекты сообщества с разным набором инструментов и разными лицензиями. Схема описывает работу с проектом в Git; рабочие базы с данными 1С остаются за её пределами.
Кто делает сервер
Для 1С:EDT есть серверы сообщества, а официального сервера от 1С в проверенных источниках нет, поэтому выбор идёт по набору инструментов, лицензии и совместимости с вашей версией EDT.
Поиск по GitHub показывает несколько проектов с названием EDT-MCP от разных авторов, Каталога, одобренного фирмой 1С, в поиске нет совсем, а отметки «официальный» в README этих проектов нет. Поэтому во внутренней записке и в договоре с подрядчиком сервер называют честно: подключаемый модуль сообщества. Ответственность за его выбор лежит на команде разработки, и записать это полезно заранее, пока установка ещё впереди.
Перед установкой сверяют три вещи. Первая — совместимость: в README одного из проектов перечислены поддерживаемые линейки EDT (на 5 октября 2026 года указаны 2026.1 и 2026.2), у других проектов список свой. Вторая — лицензия: тот же проект распространяется под AGPL-3.0, и юристу компании полезно прочитать её условия до использования во внутренней сборке. Третья — набор инструментов: часть из них только читает проект, часть правит модули и метаданные, а один, по описанию проекта, выполняет произвольное выражение BSL в приостановленной сессии отладки.
Последняя деталь определяет роль агента. В README прямо сказано, что каждый подключённый клиент может вызвать каждый инструмент, поэтому всё, что дотянулось до адреса сервера, считают полностью доверенным. По умолчанию сервер слушает только локальный адрес, а для разрушающих инструментов проект предусматривает диалог подтверждения у человека; настройку этого диалога проверяют до запуска. Доступ к данным программы разбирает статья про MCP для 1С; здесь речь только о среде разработки, где живёт код конфигурации.
Что агент читает
Читающие инструменты безопаснее всего: они возвращают текст проекта, а изменять там нечего. Для первой недели работы хватает такого набора:
- структура модуля: список процедур и функций с экспортными методами;
- ошибки проекта, которые EDT уже нашёл при проверке;
- поиск ссылок на процедуру по всей конфигурации;
- справка платформы по методу, который встретился в коде;
- метаданные объекта: реквизиты, табличные части, формы.
Условный пример: в модуле менеджера документа лежит процедура расчёта скидки, и разработчик просит агента найти все места вызова и описать, что изменится при другом правиле округления. Полный перебор вызовов делает инструмент поиска ссылок, агент собирает из его ответа пояснение, а разработчик сверяет каждую строку с реальным модулем. Утверждение «вызывается только в двух местах» без списка этих мест считается непроверенным и в работу идти может только после сверки с поиском EDT.
Часть проектов добавляет инструменты для информационных баз, журнала регистрации и запуска клиента. В рабочей схеме этой статьи они выключены: в разрешениях клиента отметьте только читающие вызовы и один вызов записи модуля, остальное агенту недоступно. Тогда содержимое справочников и документов остаётся за пределами контекста модели, а ошибки конфигурации обсуждаются на уровне кода. Если отключить вызовы вручную в клиенте затруднительно, их убирают на стороне сервера настройками проекта либо берут сборку с урезанным списком инструментов, и после смены списка читающий сценарий прогоняют заново.
Тестовая правка
Первую правку делают на копии. Задача должна быть маленькой и проверяемой, например изменить текст сообщения пользователю в одной процедуре. Такая задача позволяет увидеть, как агент обращается с кодом, как он ссылается на найденные места и насколько аккуратно оформляет изменение, а риск остаётся на уровне одной строки.
- Создайте ветку от основной и отдельную рабочую область EDT с копией проекта.
- Разрешите клиенту читающие инструменты и запись одного модуля; все прочие вызовы оставьте без разрешения.
- Поставьте задачу с границей: какая процедура меняется, какой файл остаётся нетронутым, что считать готовым результатом.
- Откройте diff в Git до любой сборки и убедитесь, что изменились только ожидаемые строки.
После diff видно главное: агент сделал ровно то, что просили, либо захватил соседний код. Лишние строки означают, что граница в задаче была расплывчатой; её уточняют и повторяют правку с чистого листа, а лишнее откатывают. Каждую такую попытку полезно записать: какая была формулировка, что получилось, что пришлось исправить. Из этих записей складывается шаблон постановки для следующих задач. Пока изменение лежит в ветке, вернуть прежнее состояние можно одной командой Git. Такой порядок оставляет решение за человеком, а сервер EDT MCP превращается в удобный способ передать модели текст проекта и получить предложение.
Какую процедуру в вашей конфигурации можно доверить тестовой правке?
Проверка сборки
Одного ответа агента о готовности для приёмки мало. Доказательство дают проверки, которые запускает система или скрипт, а агент пересказывает их результат своими словами и показывает, где именно появилась ошибка.
| Проверка | Кто запускает | Признак успеха |
|---|---|---|
| Список ошибок проекта в EDT | Разработчик или инструмент сервера | Новых ошибок по сравнению с веткой-основой нет |
| Сборка и загрузка в тестовую базу | Скрипт сборки на тестовой базе | Загрузка завершилась без сообщений об ошибках |
| Модульные тесты проекта, если они есть | Скрипт или CI | Все тесты, которые проходили до правки, проходят и сейчас |
| Ручной сценарий в тестовой базе | Разработчик | Поведение процедуры соответствует постановке |
Тестовая база здесь отдельная, с отдельным пользователем и заполнена обезличенными данными. Если у проекта нет модульных тестов, правку принимают по ручному сценарию, записанному заранее, а общее впечатление в расчёт идёт в последнюю очередь. Если сервер умеет запускать сборку, это ещё одна кнопка в EDT; самостоятельная сборка рабочей базы агенту запрещена: рабочую базу обновляет человек по регламенту компании.
Полезно сохранять результаты в одном месте, например в описании pull request: список ошибок до правки, список после, вывод сборки и отметку о ручном сценарии. Накопив несколько правок, по такой записи легко ответить, какие правки агента прошли без замечаний, а какие возвращались на доработку, и это основание для решения, расширять ли набор разрешённых инструментов.
Review разработчика
Решение о слиянии принимает разработчик, который прочитал diff целиком. Права на запись в основную ветку проверяет сервер Git: защита ветки и обязательное одобрение pull request работают независимо от того, что агент написал в ответе. Просьба в промпте вроде «запись в основную ветку запрещена» защитой считаться нельзя, это лишь пожелание к тексту.
Review начинают с вопросов к самому изменению: совпадает ли оно с задачей, затронуты ли экспортные методы, есть ли правки метаданных, о которых в постановке задачи упоминания нет. Если у сервера есть инструменты создания и удаления объектов метаданных, такие правки смотрят отдельно и вручную: открывают изменённые объекты в конфигураторе EDT, сверяют состав реквизитов и форм с описанием задачи, проверяют зависимые подсистемы и роли. Автоматического принятия изменений метаданных, сделанных агентом, в этой схеме нет вообще. Чем скучнее первый результат ревью, тем надёжнее схема: если разработчик спокойно листает diff, значит правка попала в границы задачи. Рядом полезно открыть статью про нейросеть для программиста 1С: она показывает, где агент приносит пользу в повседневной работе.
Возьмите один модуль и один читающий сценарий: попросите агента описать процедуру и найти её вызовы, затем сверьте список с поиском ссылок в EDT. Если нужен проект с настроенными правами, веткой и приёмкой, обсудите с нами внедрение ИИ в разработку.