Инструменты

Все инструменты edt_*: чтение живой модели, запись штатным движком среды и отладка запущенной информационной базы.

Имена инструментов – edt_* в snake_case, параметры – camelCase: projectName, fqn, queryText. Имя объекта пишется кириллицей, как в конфигурации, а префикс типа – по-английски: Catalog.Контрагенты, Document.ЗаказКлиента. MCP-хост показывает агенту инструменты всех серверов одним списком, поэтому имя должно нести контекст само. Отсюда и префикс edt_: edt_rename говорит, что именно переименовывает, а голый rename – нет.

Параметр, которого инструмент не объявляет, отменяет весь вызов. В отказе названо близкое имя (deleteContents → deleteContent) и перечислено то, что инструмент принимает. Молчаливый пропуск незнакомого параметра отчитался бы об успехе там, где сделано было другое.

Вместе инструменты замыкают весь цикл, не выходя из MCP: создать, разработать, собрать, поставить, отладить.

Полный цикл поставки через MCP

Чтение

Инструмент	Что возвращает
`edt_projects` · `edt_project_errors`	Открытые проекты рабочей области: имя, путь на диске, natures и признак проекта 1C:EDT. Дальше – проблемы валидации EDT по проекту: сообщение, severity, ресурс, строка. Список сужается через `fqn`, `modulePath` или `severity`, считается через `countOnly`, а с `brief` каждая проблема занимает одну строку. С этого стоит начинать: отсюда видно, к чему вообще можно обращаться. Возвращается оценка самой EDT, а вызов метода, которого нет в другом модуле, EDT считает предупреждением `WARNING` (`SU239`, “Свойство (метод) объекта не обнаружено”). Ошибка – только неопределённый вызов без имени модуля, поэтому проверка сгенерированного кода читает и предупреждения. `modulePath` достаёт одни лишь маркеры Eclipse. Маркер проверки EDT адресован объектом, поэтому, чтобы увидеть оба вида, сужать надо через `fqn`. Если `fqn` называет форму (`...Form.<Имя>`), сверка идёт и по имени формы, иначе отвечали бы и другие формы того же объекта. Маркер – это снимок, поэтому каждая проблема сверяется со своим файлом: `stale` – маркер старше последнего изменения файла на диске, `unsynchronized` – рабочая область это изменение ещё не прочитала. В сводке есть счётчики (`staleCount`, `unsynchronized`), а `hint` говорит, что с этим делать. `refresh=true` перечитывает суженную область с диска и делает инкрементальную сборку перед чтением маркеров. Для одного модуля это секунды, тогда как `edt_clean_project` пересобирает всё.
`edt_check_info`	Что проверка означает на самом деле: описание, примеры неправильного и правильного кода и ссылки на стандарты разработки 1С, которые за ней стоят, – по-русски или по-английски. Работает в паре с `edt_project_errors`, который называет сработавшую проверку. Тот отвечает на вопрос “что”, этот – на вопрос “почему”. Спрашивать можно по идентификатору проверки или вставкой текста проблемы. Проверка, у которой идентификатор – короткий код, находится по заголовку.
`edt_metadata_objects` · `edt_metadata_details`	Объекты метаданных верхнего уровня, при желании с фильтром по типу и по подстроке имени. Дальше – свойства одного объекта и его структура: реквизиты, табличные части, формы, команды, макеты, измерения, ресурсы, значения перечислений, и у каждого реквизита тип.
`edt_find_references` · `edt_outgoing_calls` · `edt_outgoing_structures`	Куда идут вызовы. Входящие ссылки на объект метаданных берутся из индекса EDT, а с параметром `method` возвращаются места вызова `CommonModule.X.method` в BSL. Обратное направление показывает, какие методы вызывает модуль, метод или форма на уровень наружу, с числом мест вызова и признаком слоя ExtAPI. Третий инструмент читает, насколько может, ключи верхнего уровня `Структуры`, переданной каждому квалифицированному исходящему вызову.
`edt_module_text` · `edt_go_to_definition` · `edt_symbol_info`	Чтение BSL. Текст модуля или одного его метода, со списком процедур и функций и их сигнатурами, по FQN или по modulePath. Определение символа в позиции: вид цели, имя, объект-владелец, расположение. И тип в позиции: элемент под курсором и вычисленные типы значения выражения.
`edt_search_modules`	Полнотекстовый поиск по модулям BSL проекта, подстрокой или регулярным выражением, с необязательным фильтром пути. Чтение идёт через буферы файлов Eclipse, поэтому модуль, открытый в редакторе, ищется в текущем виде, вместе с несохранёнными правками. `edt_find_references` отвечает на вопрос “кто вызывает этот метод”, а этот – на вопрос “где встречается такой текст”.
`edt_validate_query`	Проверяет запрос 1С по живым метаданным проекта: синтаксис и семантику, поэтому несуществующие таблицы и поля и ошибки типов возвращаются с позициями. Принимает текст запроса либо адрес модуля (`modulePath`, при желании один `method`). Для модуля мост сам достаёт из живого текста литералы запросов с обрамлением `\|` и проверяет каждый. Пакет проверяется и как целое, чего EDT не делает. Запрос, читающий временную таблицу, которую ни один предыдущий запрос не создал (`ПОМЕСТИТЬ`) или которую предыдущий запрос уничтожил, делает текст невалидным. Для литерала из модуля это лишь заметка `INFO`: таблицу может дать общий менеджер временных таблиц или другой литерал.
`edt_form_structure` · `edt_form_render` · `edt_picture_export`	Формы и изображения. Дерево элементов управляемой формы – поля, группы, таблицы, кнопки, декорации – с привязками данных, статическими visible/enabled/readOnly, обработчиками у каждого элемента, свойствами полей ввода, связкой команды с кнопкой и условным оформлением, а вместе с ним реквизиты, команды, параметры и обработчики формы. Та же форма, отрисованная в PNG штатным offscreen-рендером EDT, с выбором варианта интерфейса и темы. И содержимое CommonPicture из его Picture.zip.
`edt_platform_help`	Синтакс-помощник платформы 1С:Предприятие из поставки EDT: настоящая справка по API – объекты, методы, свойства, события, по-русски и по-английски. Поиск по имени или чтение страницы текстом. Сигнатуру лучше посмотреть, чем угадать.

Запись

Инструменты записи меняют модель штатным движком EDT, а не текстовой заменой. Каждому нужен токен, и каждый по умолчанию ничего не делает: apply=false стоит изначально и возвращает план. apply=true вносит изменение и сериализует .mdo.

Инструмент записи	Что делает
`edt_create_object` · `edt_delete_object`	Создаёт объект верхнего уровня – справочник, документ, перечисление, регистр сведений и прочие – через фабрику EDT и инициализатор типа и регистрирует его в Configuration. Удаление идёт каскадом: вместе с объектом уходят все ссылки в метаданных и в BSL, поэтому нужен `force`.
`edt_add_attribute` · `edt_modify_attribute` · `edt_remove_attribute`	Добавляет объекту метаданных реквизит с проверенными типом, klass, синонимом и комментарием; меняет у существующего тип, синоним или комментарий; удаляет реквизит. Удаление сначала проверяет ссылки и отказывает, пока они есть, если не передан `force`.
`edt_rename`	Переименовывает объект или член и переносит за ним все ссылки в метаданных и в BSL через штатный движок рефакторинга. Нужен `force`: переименование ломает всё, что построено на старом имени.
`edt_add_method` · `edt_delete_method`	Добавляет и удаляет процедуру или функцию в BSL модуля, обе операции идут по модели. Вставка отказывает, если результат перестаёт разбираться. Вырезание забирает прилегающий документирующий комментарий, а план возвращает точный текст, который уйдёт, – поэтому и нужен `force`. Модуль адресуется по FQN, включая `HTTPService.X` и `WebService.X`.
`edt_add_route`	Добавляет в `HTTPService` маршрут: шаблон URL и один HTTP-метод. Инструмент генерирует `uuid` и шаблона, и его метода, а писать эти идентификаторы руками – ровно то, ради чего мост и заведён. Он же разрешает перечисление `httpMethod`, а с `createHandler` вставляет в модуль сервиса заготовку `Функция <handler>(Запрос)`.
`edt_add_form`	Добавляет объекту метаданных управляемую форму штатным генератором EDT – тем же, что стоит за мастером “Новая форма”. Форма, её элементы и модуль генерируются, а не пишутся руками в XML.
`edt_add_form_attribute` · `edt_modify_form_attribute` · `edt_remove_form_attribute`	Добавляет, меняет и удаляет реквизит формы, а с параметром `columnOf` – колонку реквизита типа ТаблицаЗначений. Идентификаторы выдаёт служба идентификаторов формы. Кроме грамматики типов метаданных принимаются платформенные типы, допустимые у формы (`ТаблицаЗначений`, `СписокЗначений` и другие), и объектные типы `ВнешняяОбработкаОбъект.X` и `СправочникОбъект.X` – тот вид, который несёт основной реквизит. Удаление перечисляет связанные элементы и требует `force`.
`edt_add_form_command` · `edt_modify_form_command` · `edt_remove_form_command`	Добавляет, меняет и удаляет команду формы. При добавлении можно заодно записать в модуль формы заготовку процедуры-обработчика, а если модуля не было – создать его. Удаление перечисляет связанные кнопки и требует `force`.
`edt_add_form_handler`	Регистрирует обработчик события формы или её элемента. Это та самая запись `handlers` в `Form.form`, без которой платформа процедуру не вызывает, а валидация молчит. Список допустимых событий берётся у самой EDT, поэтому неверно названное событие отвергается вместе с перечнем. По желанию пишет и заготовку – с сигнатурой, которую объявляет событие, и с директивой, которую задают его среды выполнения.
`edt_add_form_item` · `edt_modify_form_item` · `edt_remove_form_item`	Добавляет, меняет и удаляет визуальные элементы формы: поле, таблицу, кнопку, группу, декорацию. Работа идёт через штатный `IFormItemManagementService` – ту самую службу, которую зовёт редактор форм. Таблица, связанная с реквизитом типа ТаблицаЗначений, получает колонки автоматически. Заданный таблице `titleRu` остаётся у таблицы, а сгенерированные колонки сохраняют штатный заголовок EDT. Правка умеет и переименовать элемент через `newName`: имя элемента живёт в модели формы, а процедуры-обработчики сохраняют свои. Удаление забирает всё вложенное и требует `force`.
`edt_adopt_object`	Заимствует объект базовой конфигурации в проект расширения штатным `IModelObjectAdopter`. Пока это не сделано, расширение не может перехватить у объекта ничего; этим же шагом достраивается `edt_create_extension`.
`edt_import_project`	Регистрирует в рабочей области каталог проекта, который уже есть на диске: “Импорт существующего проекта” без диалога. Этого шага не хватало в цикле “создать – поработать – удалить”. Расширение в режиме изменения и контроля сверяется с базовым проектом на целевом релизе, а тот лежит в другом рабочем дереве. На диске ничего не переписывается, а своё имя позволяет держать рядом две рабочие копии одного репозитория.
`edt_create_extension` · `edt_create_external_object`	Начинает проект. Либо проект расширения конфигурации к базовому через `IExtensionProjectManager`, где корневая Configuration – базовая конфигурация, заимствованная так же, как это делает мастер, что и делает проект пригодным для загрузки в информационную базу; там же задаются префикс имён, назначение (Адаптация, Дополнение или Исправление) и синоним. Либо проект внешней обработки, с которого начинается цикл “обработка → .epf”.
`edt_clean_project` · `edt_delete_project`	Заканчивает с проектом. Либо сбрасывает результаты сборки, чтобы валидация отработала заново: это диалог “Очистить” из EDT, вызванный программно. Инструмент возвращает число замечаний до и после и ждёт, пока оно перестанет меняться, потому что устаревший маркер, переживший свою причину, хуже отсутствия маркера. Для одного модуля, изменённого на диске, есть лёгкая замена – `edt_project_errors` с `refresh=true`. Либо удаляет проект из рабочей области средствами Eclipse, чтобы не осталось фантома. Удаление требует `force`, потому что вернуть проект нечем.
`edt_build_extension` · `edt_dump_external_object`	Собирает бинарники: `.cfe` из проекта расширения, `.epf` или `.erf` из внешней обработки или отчёта. Оба умеют обойти резолвер платформы EDT, когда тот не даёт толстый клиент. Тогда модель выгружается в XML конфигуратора прямо в процессе, а файл собирается полной установкой 1С с диска во временной базе, которая потом удаляется. `logPath` кладёт лог сборки платформы рядом с артефактом. Выгрузка уходит на дисковый маршрут и когда отказал штатный дампер; `route` задаёт маршрут явно, `edt` или `disk`; автогенерация выгрузок возвращается на место, если отказ её выключил.

Информационные базы, кластер и платформа

Эти инструменты обращаются к работающей информационной базе, а не к модели в EDT. Дорог туда четыре, и они не взаимозаменяемы. Какую берёт инструмент, видно в столбце Через.

штатная синхронизация EDT – то, чем пользуется сама среда. Она открывает собственное соединение с базой и не умеет принимать учётные данные снаружи интерфейса, поэтому останавливается на базе с аутентификацией пользователей.
ibcmd идёт прямо к базе данных, путём или координатами СУБД, поэтому кластерной базе доступ к кластеру не нужен. Учётной записи 1С у режима extension нет вовсе.
агент конфигуратора – это конфигуратор, запущенный с /AgentMode. Он принимает команды по SSH и проходит аутентификацию как пользователь базы, поэтому достаёт то, что недоступно остальным двум. Мост держит по одному агенту на базу: поднимать долго, держать дёшево.
rac – сам кластер, а сеансы живут именно там. Ни агент, ни ibcmd их не видят.

Инструментам, которые меняют базу, нужен токен, и по умолчанию они возвращают план – ровно как инструменты записи выше.

Инструмент	Через	Что делает
`edt_infobases` · `edt_platform_installations`	EDT	С чем работает платформенная сторона. Зарегистрированные в EDT информационные базы с именем, uuid и строкой соединения, а к ним привязки открытых проектов. Дальше – установки 1С:Предприятие, из которых EDT выбирает при выгрузке `.epf` и `.erf` и при создании базы: каждая разрешена до конкретной установки с толстым клиентом, плюс полные установки, найденные на диске.
`edt_designer_agent`	агент	Жизненный цикл агентов конфигуратора, которыми управляет мост: список, запуск, остановка, уборка. Агент – это конфигуратор в режиме `/AgentMode` с открытым сеансом базы, проходящий аутентификацию как пользователь базы; так мост и добирается до базы, недоступной остальным транспортам. Агент поднимается по требованию и живёт между вызовами, а остановка освобождает сеанс на сервере. Простояв дольше `EDT_BRIDGE_AGENT_IDLE_MINUTES`, агент останавливается сам, потому что занимает клиентскую лицензию и сеанс конфигуратора; по умолчанию это 30 минут, а `off` держит агентов вечно. После упавшего агента остаётся сеанс, который держит блокировку конфигурирования базы. Этот остаток подметается перед каждым запуском, при `stop` для базы, чей агент умер, и по требованию через `action=sweep`. Принадлежность доказывается следом, который агент пишет о себе, а не угадывается по хосту и пользователю сеанса.
`edt_infobase_config_state`	агент	Применена ли конфигурация базы данных – та, которую исполняют сеансы, – или обновление ещё ждёт? Отвечает на это сама платформа. Обновление запускается, а подтверждение затем отклоняется, поэтому ничего не применяется, и ожидающее обновление возвращается полным списком изменений структуры. Вызов идёт через агент конфигуратора, поэтому доступна и серверная база с аутентификацией пользователей.
`edt_update_database_config`	агент	Применяет конфигурацию базы данных. Это шаг, после которого работающие сеансы начинают исполнять ту конфигурацию, которую хранит база. Загрузка проекта в базу этого не делает: до применения каждый сеанс исполняет прежний код, и так выглядит только что добавленный маршрут HTTP-сервиса, отвечающий 404. По умолчанию возвращает план. `sessionTermination=force` завершает удерживающие базу сеансы, когда нужна монопольная блокировка.
`edt_update_infobase`	EDT · агент	Обновляет конфигурацию базы из проекта EDT. По умолчанию через штатный механизм синхронизации: изменения структуры базы данных подтверждаются автоматически, конфликт прерывает работу, а база с пользователями этому механизму недоступна. С `transport=agent` проект выгружается в XML конфигуратора и грузится через агента. Это единственная дорога в серверную базу с пользователями, и конфигурация базы данных применяется следом.
`edt_create_infobase` · `edt_register_platform`	EDT · установка с диска	Создаёт пустую файловую базу и регистрирует её в списке EDT, а если под нужную версию EDT ничего не нашла, берёт полную установку с диска. Второй инструмент регистрирует полную установку в EDT, чтобы ею мог пользоваться её собственный движок.
`edt_extension_properties`	агент · ibcmd	Читает и задаёт то, как расширение зарегистрировано в базе: безопасный режим, защита от опасных действий, активность, область действия. Ни сборка `.cfe`, ни обновление из EDT этого не решают, а только что зарегистрированное расширение получает безопасный режим и защиту включёнными. Расширение, которое меняет методы базовой конфигурации, под ними не работает. Передайте проект расширения – и результат скажет, тот ли это случай. По имени из EDT вызов идёт через агента, которому доступна серверная база с пользователями; по явным координатам СУБД – через `ibcmd`, которому она недоступна.
`edt_delete_extension`	агент	Снимает расширение с информационной базы. Этим шагом замыкается жизненный цикл: создать, загрузить, настроить, удалить. План сначала читает текущие свойства расширения, поэтому на неверное имя ответ приходит внятный. Кроме apply нужен `force`: конфигурация расширения хранится в базе, и вернуть её отсюда нечем.
`edt_infobase_sessions`	rac	Сеансы кластера 1С через `rac`: перечислить по базе или по виду приложения и завершить. Ни агент, ни `ibcmd` этого не умеют, потому что сеансы живут в менеджере кластера. Инструмент нужен, когда база отказывается конфигурироваться. Убитый, а не закрытый сеанс конфигуратора продолжает держать блокировку конфигурации и виден здесь как сеанс `Designer`. Завершение по умолчанию возвращает план и требует force.
`edt_infobase_maintenance`	rac	Окно обслуживания вокруг обновления базы. `begin` поднимает `scheduled-jobs-deny`, по запросу ещё и `sessions-deny` с кодом доступа, ждёт, пока сеансы иссякнут сами, и отвечает “clear to update”. `end` опускает оба флага, включая `sessions-deny`, поднятый другим вызовом `begin`, и сообщает, если флаг остался поднятым. `status` только отчитывается. Смысл в том, что на живой базе сеансы BackgroundJob пересоздаются каждую минуту, и завершать их бесполезно. Сначала запрет – и убивать никого не нужно. Нужен администратор базы, по умолчанию возвращается план.
`edt_infobase_dump`	ibcmd	Выгружает информационную базу в `.dt` через `ibcmd`. Это та резервная копия, которую стоит снять перед применением конфигурации к базе данных, а раньше мост снять её не мог. База адресуется путём или координатами СУБД, перезаписывать существующий файл инструмент отказывается, по умолчанию возвращает план. В самой базе ничего не меняется, но выгрузка читает все её данные, поэтому нужен токен.

Отладка

Эти инструменты подключаются к серверу отладки (dbgs) запущенной базы и управляют выполнением. Работать нужно на тестовом стенде, а не на рабочей базе. Всем нужен токен, а edt_evaluate закрыт плотнее всех.

Инструмент отладки	Что делает
`edt_debug_attach` · `edt_debug_detach`	Подключает сеанс отладки к серверу отладки запущенной базы и возвращает `sessionId` для остальных инструментов отладки. Отключение завершает сеанс и освобождает базу.
`edt_debug_inspect` · `edt_debug_control`	Перечисляет потоки сеанса, а у приостановленных – кадры стека BSL и переменные верхнего кадра, только на чтение. Дальше управляет выполнением: `suspend` и `resume` либо `stepOver`, `stepInto` и `stepReturn` у приостановленного потока.
`edt_evaluate`	Вычисляет произвольное выражение BSL в приостановленном кадре, то есть исполняет код против живой базы. Нужны токен, `allowCodeExecution=true` в самом вызове и серверный переключатель `EDT_BRIDGE_ALLOW_EVALUATE=1`, выключенный по умолчанию.

Инструменты самой обвязки

Один инструмент приходит не от моста внутри EDT: он действует на эту EDT, а отчитаться о процессе, который сам же и завершил, инструмент внутри него не может. Его отдаёт edt-bridge-mcp: перечисляет рядом с инструментами моста и отвечает сам, ничего не пересылая.

Инструмент обвязки Что делает

edt_open_gui Передаёт рабочую область клиентской EDT. Останавливает headless за мостом, дожидается, пока его процессы действительно исчезнут, и открывает окно EDT на той же рабочей области. Ждать важно: порт замолкает заметно раньше, чем умирает среда, и именно этот остаток потом ищут в диспетчере задач. force снимает то, что не завершилось в срок, включая keepalive-обёртку: она родитель, и убийство дерева снизу до неё не достаёт. Мост возвращается сам, как только клиентская EDT загрузит плагин.

Инструмент обвязки	Что делает
`edt_open_gui`	Передаёт рабочую область клиентской EDT. Останавливает headless за мостом, дожидается, пока его процессы действительно исчезнут, и открывает окно EDT на той же рабочей области. Ждать важно: порт замолкает заметно раньше, чем умирает среда, и именно этот остаток потом ищут в диспетчере задач. `force` снимает то, что не завершилось в срок, включая keepalive-обёртку: она родитель, и убийство дерева снизу до неё не достаёт. Мост возвращается сам, как только клиентская EDT загрузит плагин.