MCP-1C шлюз и сервер MCP для 1С
Личный кабинет Попробовать бесплатно
Инструменты

Инструменты Профессиональной версии

Документы 1С, печать PDF и Excel, массовый анализ кода, граф зависимостей, генерация тестов, документации и .epf обработок.

Включает все инструменты Расширенной, плюс работу с документами, печать и выгрузку из 1С, глубокий анализ всей кодовой базы, архитектурную визуализацию, автогенерацию документации, генерацию тестов и .epf обработок, навигацию по типовым конфигурациям и структурный diff расширений .cfe. Анализ по выгрузке может требовать предварительного построения кэша; инструменты document и print_export обращаются к подключённой базе 1С.

document: документы и непроведённые черновики

Профессиональная · с v2.43.0

Инструмент находит документы, читает реквизиты и строки, создаёт и изменяет непроведённые черновики после подтверждения пользователя. Доступны прямое HTTP-подключение к 1С и опрос; прокси-подключение этот инструмент не поддерживает. В режиме опроса нужны оба расширения MCP_HTTPService и MCP_Polling одной поставки; публиковать HTTP-сервис 1С не требуется. Порядок обновления описан в быстром старте.

Действия:

  • describe — доступные виды документов, их поля и табличные части; для ссылочных полей — поиск значений, для перечислений — допустимые варианты.
  • list — поиск по периоду, состоянию проведения и типизированным отборам. Период включает from и не включает to; даты задаются в локальном времени сеанса 1С. Размер страницы limit — от 1 до 100, по умолчанию 20; продолжение списка передаётся парой after_date и after_uuid из ответа.
  • get — чтение выбранного документа и его непрозрачной version, необходимой для обновления.
  • create — создание непроведённого черновика.
  • update — изменение непроведённого черновика с version из последнего чтения.

Для записи обязателен idempotency_key. Перед ней MCP-клиент показывает подготовленные данные в форме подтверждения и запрашивает явное согласие. Ответа «да» в чате недостаточно; клиент без поддержки такой формы записывать не сможет. Пропущенные поля и табличные части сохраняются, а переданная табличная часть заменяется целиком: [] очищает её. При конфликте версии прочитайте документ заново и повторно согласуйте изменение. Если ответ после записи потерян (outcome_unknown), восстанавливайте ту же операцию с теми же данными и ключом после нового согласия, не создавая новую запись.

Проверяются обычные права пользователя 1С и RLS; при опросе это права пользователя регламентного задания. Доступность записи проверяется для конкретной конфигурации и сеанса. Запись требует управляемых блокировок, недоступна при активном разделении данных и для базы с флагом --read-only. Неопределённые условия доступа не считаются разрешением. При записи выполняются штатные проверки и обработчики конфигурации; инструмент не проводит и не удаляет документы и не отправляет платежи в банк.

Пределы: до 1000 строк документа, запрос до 256 КиБ, ответ до 1 МиБ. Перед первой записью проверьте сценарий на копии базы. Практический пример: черновик, PDF и Excel.

Настройка создания и изменения документов

Успешная установка расширений не означает готовность к записи документов. Установщик сохраняет настройки безопасности. Обычные запросы, чтение, анализ и печать не требуют включать запись через document; для них сохраняются собственные права и требования конфигурации.

Создание и изменение черновиков требуют, чтобы расширение MCP_HTTPService при открытии сеанса определило текущего пользователя 1С. При стандартном безопасном режиме расширения эта инициализация недоступна. Если document возвращает receipt_unavailable, операция не допущена: не повторяйте её с новым ключом и не пытайтесь обойти отказ выдачей административных прав.

Настройку выполняет администратор 1С:

  1. Сделайте и проверьте резервную копию базы вместе с данными расширений. Сначала настройте восстановленную копию. Обновляйте существующее MCP_HTTPService на месте: не удаляйте его и не создавайте заново, иначе потеряются данные защиты от повторного выполнения операций. Для опроса обновите также существующее MCP_Polling из той же поставки.
  2. Согласуйте допустимые настройки безопасности именно для MCP_HTTPService. Если политика безопасности допускает доверие расширению, администратор отключает безопасный режим этого расширения, чтобы разрешить выполнение модуля сеанса. Это решение о доверии расширению, а не обязательный шаг для обычного чтения и печати. Не отключайте защиту автоматически или для всех расширений. Если ваша политика не допускает необходимую настройку, оставьте её включённой: запись документов останется недоступна.
  3. Назначьте пользователю коннектора роль MCP_ОсновнаяРоль штатным способом конфигурации и только необходимые деловые права на документы. Если доступом управляют профили БСП, используйте утверждённый профиль и штатное обновление прав. Для опроса проверяйте пользователя регламентного задания. После изменения настроек откройте новый сеанс.
  4. На копии проверьте прежние запросы и печать, затем вызовите инструмент document с action: "describe" для нужного вида документа и проверьте write_supported и write_error. Проверьте создание и изменение одного тестового непроведённого черновика с подтверждением пользователя. При повторном подтверждении того же запроса с тем же idempotency_key должна возвращаться прежняя операция без второго документа. Проверяйте под обычным пользователем коннектора, а не только под администратором.

Для записи также нужны управляемые блокировки; активное разделение данных и --read-only исключают запись. Если остаётся receipt_unavailable, администратор должен проверить применение расширения, инициализацию сеанса и права именно этого пользователя. Не удаляйте расширение или его данные и не расширяйте права, чтобы скрыть ошибку. До устранения причины запись остаётся закрыта.

print_export: штатная печать и Excel

Профессиональная · с v2.43.0

PDF и XLSX формирует сама 1С. Сначала вызовите describe, чтобы узнать поддерживаемые команды печати, варианты отчётов, колонки и параметры именно вашей базы. Наличие инструмента не означает поддержку любой конфигурации или печатной формы. Доступны прямое HTTP-подключение и опрос с обоими расширениями одной поставки; прокси-подключение не поддерживается. При опросе действуют права пользователя регламентного задания.

Действия:

  • describe — доступные документы, отчёты и их поддерживаемые возможности.
  • print_document — выбранная штатная печатная форма одного документа в PDF или XLSX.
  • export_report — штатный вариант отчёта на схеме компоновки данных с согласованными типизированными параметрами, в PDF или XLSX.
  • export_document_list — список одного вида документов в XLSX: период, выбранные колонки и отборы.

Для списка документов период включает from и не включает to, даты учитываются во времени сеанса 1С. Пределы одной выгрузки — 1000 строк, 32 колонки и 366 дней. Превышение возвращает ошибку, а не усечённый файл. Номера и другие идентификаторы сохраняются текстом, даты — ISO-текстом, числа длиннее 15 значащих цифр — точным десятичным текстом без округления Excel.

Результат — одно вложение MCP с байтами файла и сведениями об имени, MIME-типе, размере и SHA256; размер до 8 МиБ. Отдельной ссылки для скачивания инструмент не создаёт, способ открытия и сохранения зависит от MCP-клиента.

Не поддерживаются внешние печатные формы, обработчики только для клиентской формы 1С, личные сохранённые варианты и настройки отчётов, доступные только из формы. Произвольный BSL и произвольные настройки компоновки передавать нельзя. Штатные обработчики и выражения установленной конфигурации выполняются с правами пользователя. Если нужная команда не поддерживается, используйте обычный клиент 1С.

Пути к выгрузкам в v2.30.0

Каталоги и имена файлов, которые инструмент получает в параметрах вызова, теперь ограничены выгрузками зарегистрированных баз. Прежде несколько инструментов принимали произвольный путь и могли прочитать, записать или удалить что-то за пределами предполагаемого каталога; теперь такой путь разрешается только внутри каталога выгрузки, зарегистрированного флагом --dump. Проверка идёт до первого открытия файла, когда путь приводится к каноническому виду, символьные ссылки в нём раскрываются, а результат обязан совпадать с зарегистрированным каталогом или лежать внутри него, поэтому и .., и абсолютный путь мимо всех выгрузок, и ссылка наружу отклоняются до чтения. Внутри разрешённого каталога обращения к файлам вдобавок удерживаются средствами операционной системы, которая проверяет каждый элемент пути на своей стороне, хотя часть разбора выгрузки и служебные кэши по-прежнему открывают уже проверенный путь напрямую. Мы рекомендуем обновиться всем, кто работает на Профессиональной и Корпоративной версиях.

Ограничение затрагивает explain_exchange_plan, autodoc, archviz, typicalconfigs, explain_rls, code_review, update_helper, epfgen, testgen, code_read и выбор базы в инструменте hub. У code_read при этом параметра с путём нет вовсе, он добирается до выгрузки только через зарегистрированную базу, а инструмент hub есть лишь в Корпоративной сборке, так что на Профессиональной ни в том, ни в другом менять в своих вызовах нечего. Чаще всего оно незаметно, потому что вызовы с параметром base и разовые запуски через собственные флаги оператора (--autodoc-out, --testgen-output, --epfgen-output, --typicalconfigs-output) работают как прежде. Заметным оно становится там, где путь передавался абсолютным и вёл за пределы зарегистрированных выгрузок: такой вызов теперь отклоняется.

Чтобы вызов, работавший раньше, продолжил работать, укажите нужный каталог при запуске сервера флагом --dump, и тогда он сам и всё, что лежит внутри него, снова разрешены. В мультибазовом режиме имя в --dump ИМЯ=ПУТЬ должно совпадать с именем базы из --base. Относительный путь принимает только explain_exchange_plan и только когда администратор настроил корневой каталог сравнения флагом --exchange-compare-root; у остальных инструментов относительного маршрута нет.

Отдельно стоит проверить два сценария, где путь по своей природе живёт вне рабочей выгрузки. Помощник обновления обычно сравнивает вашу конфигурацию с выгрузкой поставки вендора, которая лежит в стороне, поэтому либо зарегистрируйте её как базу, либо пользуйтесь разовым запуском --update-helper с флагами --vendor-new и --vendor-old, который ограничением не затронут. Сравнение расширения с базовой конфигурацией через code_review действия base_vs_ext тоже часто выполнялось по рабочему каталогу разработчика, а разового запуска у этого действия нет, поэтому каталог расширения придётся зарегистрировать.

bulk_analyze

Профессиональная

Массовый анализ кодовой базы 1С

Комплексный анализ всей кодовой базы: антипаттерны, дубли кода, мертвый код, аудит безопасности, метрики качества. Требует предварительного построения кэша командой --build-bulkanalysis.

Действия:

  • action: "summary" - сводка по всей кодовой базе: количество модулей, находок по категориям, общий балл техдолга
  • action: "findings" - антипаттерны и ошибки кода (30 правил): неоптимальные запросы, утечки ресурсов, устаревшие конструкции
  • action: "duplicates" - дубли кода (MinHash + LSH): похожие фрагменты в разных модулях с процентом совпадения
  • action: "deadcode" - мертвый код: неиспользуемые процедуры, переменные, параметры
  • action: "security" (устарело) - аудит безопасности BSL (11 правил SEC): SQL-инъекции, небезопасные вызовы, утечки данных. Устаревший алиас, используйте action: "findings" с category: "security"
  • action: "metrics" - метрики качества: LOC, цикломатическая сложность, глубина вложенности, балл техдолга (0-100)
  • action: "trends" - динамика показателей между запусками анализа

Параметры:

  • cvss_format - формат отчёта при action=findings + category=security: auto (по умолчанию, группировка по CVSS-критичности), grouped (всегда CVSS-группировка), flat (плоский список)
  • include_suppressed - включить в ответ находки, подавленные через audit:ignore: они показываются помеченными, отдельной секцией, а не скрываются. Для: findings, security (v2.23.0)

У находок безопасности приводятся оценки CVSS (вектор, балл и уровень критичности) рядом со ссылками на CWE и OWASP, что помогает приоритизировать исправления (v2.23.0).

Подавление находок прямо в коде через комментарий // audit:ignore ПРАВИЛО -- причина (построчно) или блоком // audit:ignore-begin ... // audit:ignore-end; поддерживается срок действия [expires ГГГГ-ММ-ДД]. Подавленные находки не учитываются в сводках по умолчанию, помечаются в SARIF массивом suppressions[] и возвращаются по флагу include_suppressed (v2.23.0).

В аудите безопасности (category: "security") рядом со ссылками на CWE и OWASP приводятся справочные сопоставления находок с мерами ГОСТ Р 57580.1 и приказа ФСТЭК России N 21. Это справочная информация для оценки и приоритизации; она не является сертификацией или подтверждением соответствия (v2.22.0, уточнено в v2.23.0).

Правило SEC006 даёт меньше ложных срабатываний (v2.23.0).

Требует: --dump + --build-bulkanalysis (предварительное построение кэша)

update_helper

Профессиональная

Сравнение конфигураций / помощник обновления

Сравнение конфигураций (2-way или 3-way) для подготовки к обновлению: что изменилось между вашей доработанной конфигурацией и поставкой вендора. Анализ выполняется асинхронно: действие analyze ставит задачу в очередь и сразу возвращает job_id, а статус и итоговый отчёт забираются отдельными действиями.

Действия:

  • action: "analyze" - поставить сравнение конфигураций (2-way или 3-way) в очередь и вернуть job_id
  • action: "summary" - статус задачи: queued / running / done / error с прогрессом (progress_pct)
  • action: "get_report" - итоговый отчёт сравнения (когда status=done)

Параметры:

  • dump_path + vendor_new (обязательны для analyze) - выгрузка вашей конфигурации и новой поставки вендора
  • vendor_old - старая поставка вендора; если задана, выполняется 3-way сравнение (иначе 2-way)
  • format - формат отчёта: markdown (по умолчанию), text, json, html, pdf
  • job_id (обязателен для summary и get_report) - идентификатор задачи из analyze

check_query (v2.25.0)

Профессиональная

Семантическая проверка запроса 1С по метаданным

Офлайн семантическая проверка текста запроса 1С по метаданным выгрузки. Дополняет синтаксическую проверку запроса из Открытой версии (code_execute с action: "validate"): сверяет существование таблиц и полей, разыменование через точку по ссылочным типам, применимость виртуальных таблиц. Живая база 1С не нужна.

Это отдельный инструмент верхнего уровня, а не действие консолидированного code_execute, потому что на вход принимает текст запроса, а не ссылку на объект или модуль.

Параметры:

  • query (обязательный) - текст запроса на языке запросов 1С
  • base - имя базы, если подключено несколько
  • db_target - целевая СУБД для меток критичности: postgres, mssql, postgres_pro_1c, tantor
  • format - формат вывода: text (по умолчанию) или json

Правила проверки: QRY031 сообщает о поле, которого нет у объекта метаданных; QRY032 ловит некорректное разыменование через точку, когда поле после точки отсутствует у типа, на который ссылается предыдущее поле. Проверка существования полей охватывает 8 видов объектов: Справочник, Документ, регистры сведений и накопления, планы счетов и видов характеристик, Задача, БизнесПроцесс.

Без выгрузки выполняется только синтаксическая и структурная проверка. Полная проверка существования таблиц и полей включается запуском сервера с флагами --dump и --enable-query-resolve.

Требует: --dump + --enable-query-resolve для проверок существования (без них только синтаксис)

check_bsl_api (v2.27.0)

Профессиональная

Проверка API платформы в коде BSL

Офлайн проверка текста модуля BSL по загруженному синтаксическому корпусу платформы 1С. Проверяется именно API платформы, а не стиль кода: в отличие от check_bsl (пустые блоки Исключение, транзакции, неиспользуемые переменные и прочие code smells) и от bsl_syntax_help (справочник только ищет по корпусу), этот инструмент сверяет вызовы с тем же корпусом. Живая база 1С и выгрузка не нужны.

Это отдельный инструмент верхнего уровня, а не действие check_bsl, потому что на вход принимает текст модуля, а не ссылку на объект.

Находит два вида проблем:

  • API001: вызовы устаревших глобальных методов платформы. Если корпус содержит версию признания устаревшим и рекомендуемую замену, они приводятся в сообщении.
  • API010 (рекомендательно): вызовы без префикса, которых нет в загруженном корпусе платформы. Формулировка привязана к корпусу («не найдено в загруженном корпусе платформы»), потому что отсутствие в корпусе не доказывает, что метода не существует (возможна опечатка или символ из другой версии платформы). Это всегда предупреждение, а не ошибка.

Параметры:

  • code (обязательный): исходный текст модуля BSL
  • format: формат вывода, text (по умолчанию) или json

Границы проверки: точечные вызовы вида Объект.Метод не проверяются, потому что тип приёмника не выводится; конструкторы, число и типы аргументов, значения системных перечислений вне области. Существование сверяется только по точным картам корпуса, нечёткий поиск не используется. Без загруженного корпуса (флаг --update-syntax) проверки существования и устаревания пропускаются, и в выводе явно отмечается, что корпус недоступен, чтобы тишина не читалась как успешная проверка.

Требует: обновлённый синтаксический корпус платформы (--update-syntax); без него проверки пропускаются с явной отметкой о недоступности корпуса

explain_rls (v2.27.0)

Профессиональная

Разбор прав и RLS ролей (офлайн, по выгрузке)

Офлайн разбор дерева Roles/ выгрузки конфигурации: по каждой роли показывает матрицу прав, шаблоны ограничений роли и дословные тексты ограничений доступа на уровне записей (RLS). Живая база 1С не нужна, читается только выгрузка.

Это разбор структуры, а не аудитор и не симулятор. Вывод строго структурный: (роль, объект, право, значение, текст ограничения или пусто), считанный из XML. Право, выданное без ограничения на уровне записей, помечается отдельно (значение true, без ограничения) как структурный факт.

Параметры:

  • dump_path: путь к каталогу выгрузки (содержит Roles/); обязателен, если не указан base
  • role: опциональный фильтр, показать только роль с этим именем
  • object: опциональный фильтр, показать только этот объект метаданных (например Справочник.Контрагенты)
  • with_restrictions_only: показать только права, несущие ограничение RLS (по умолчанию выключено)
  • format: формат вывода, text (по умолчанию) или json
  • base: имя базы, если подключено несколько; источник выгрузки при отсутствии dump_path

Границы: инструмент не выносит вердикт о доступе конкретного пользователя, потому что в выгрузке нет ни пользователей, ни параметров сеанса; не вычисляет эффективные права по набору ролей; не интерпретирует смысл языка ограничений, текст условия показывается дословно. Роль, чей Rights.xml не удалось разобрать (или он слишком большой, или недоступен), попадает в примечания и не выдаётся за чистую.

Требует: выгрузку конфигурации (параметр dump_path или база, подключённая через --dump)

explain_exchange_plan (v2.27.0)

Профессиональная

Обмен 1С: разбор, сравнение и карта (офлайн, по выгрузке)

Что изменилось в v2.30.0. Параметр dump_path больше не принимает произвольный каталог. В версиях с v2.27.0 по v2.29.3 инструмент читал любой каталог, внутри которого находился подкаталог ExchangePlans, а теперь путь разрешается только двумя способами: абсолютный путь принимается, если он совпадает с каталогом выгрузки зарегистрированной базы или лежит внутри него, а относительный путь принимается, если администратор настроил корневой каталог сравнения флагом --exchange-compare-root. Значения, которые прежние версии принимали, теперь отклоняются с сообщением «Путь к выгрузке отклонён», поэтому жёстко прописанный в скрипте абсолютный путь к выгрузке перестанет работать, пока вы либо не зарегистрируете эту выгрузку как базу флагом --dump, либо не настроите корневой каталог сравнения и не перепишете вызов на относительный путь внутри него. Абсолютный путь внутри корневого каталога сравнения тоже отклоняется, потому что абсолютные пути разрешаются только через зарегистрированную базу.

Инструмент работает офлайн по выгрузке конфигурации и умеет три режима, которые выбираются параметром mode. Живая база 1С не нужна ни в одном из них.

mode: plan (по умолчанию)

Разбор дерева ExchangePlans/ выгрузки: по каждому плану обмена показывает имя, синоним, флаг распределённой информационной базы (РИБ, DistributedInfoBase), включение расширений конфигурации, имена ссылок на шаблоны и состав, то есть какие объекты входят в план, плюс дословный токен авторегистрации AutoRecord.

Инструмент показывает, как обмен настроен, а не то, что реально синхронизировалось. Реквизиты самого объекта плана обмена смотрите через get_object_structure. Это разбор структуры, а не аудитор и не симулятор: данные берутся из ExchangePlans/Имя.xml и ExchangePlans/Имя/Ext/Content.xml.

Токен AutoRecord (Deny или Allow) показывается дословно, как нейтральный факт, без вывода о синхронизации: в РИБ все объекты состава могут иметь Deny и всё равно переноситься составом конфигурации.

Сам вывод этого режима не менялся: для пути, который по новым правилам по-прежнему разрешается, ответ совпадает с ответом прежних версий байт в байт.

mode: diff (v2.30.0)

Сравнение двух планов обмена в двух формах. Один и тот же план в двух выгрузках сравнивается, когда заданы dump_path, dump_path_b и plan, а два разных плана в одной выгрузке сравниваются, когда заданы plan и plan_b. Если не задано ни dump_path_b, ни plan_b, вызов отклоняется ещё до чтения файлов, потому что непонятно, что с чем сравнивать.

В ответ попадают только изменившиеся поля, а именно синоним, комментарий, признак РИБ, включение расширений конфигурации и имена ссылок на шаблоны, плюс разница состава с разделением на добавленные и удалённые объекты, изменения токена AutoRecord и число совпавших позиций. Признак clean выставляется только тогда, когда оба плана найдены, поля не менялись, состав удалось сравнить, разница пуста и ни по одной из выгрузок нет ни одного примечания. Примечания при этом собираются по всему каталогу ExchangePlans/, а не по сравниваемому плану, поэтому нечитаемый или пропущенный соседний план в той же выгрузке снимает clean, хотя разница остаётся пустой. Если различий не видно, а clean нет, причина будет в списке примечаний.

План, которого нет в одной из выгрузок, ошибкой не считается и за отсутствие различий не выдаётся: сторона помечается как ненайденная, а списки разницы остаются пустыми. Так же инструмент ведёт себя ещё в четырёх случаях: когда состав в выгрузке не задан и отбор объектов определяет формат обмена, когда файл состава есть, но прочитать его не удалось, когда состав усечён по лимиту и когда в нём есть повторяющиеся объекты. Всего таких причин пять, и каждая названа словами рядом со стороной, к которой относится.

mode: map (v2.30.0)

Карта обмена по выгрузке, в которую входят планы обмена, регламентные задания вместе с расписанием, подписки на события и признаки обмена в коде. Расписание регламентного задания показывается не выборочно: в ответ попадают все атрибуты элемента Schedule и все его непосредственные вложенные элементы в том порядке, в каком они лежат в выгрузке. Объявления пространств имён (xmlns) пропускаются, а у вложенного элемента, внутри которого есть своя структура, показывается только собранный из неё текст без разбивки на подэлементы, так что расписание с вложенностью глубже одного уровня читается как строка. Всего берётся не больше 512 полей, считая атрибуты и элементы вместе, и при срабатывании этого предела в ответе появляется примечание «расписание усечено по лимиту числа полей».

Признаки обмена в коде ищутся по семи семействам, это регистрация изменений (registration), сообщения обмена (messages), узлы плана обмена (nodes), признак загрузки обмена (dataexchange), сериализация данных (serialization), файловый обмен (files) и внешние соединения (connections). Каждый признак ищется и в русском, и в английском написании, например ОбменДанными и DataExchange, поэтому конфигурация, написанная на английском встроенном языке, тоже попадает в выдачу, а не выглядит как база без обмена.

Параметр verbs добавляет свои признаки к тому, что уже ищется, а не заменяет собой семейство. Без family поиск идёт по всем семи семействам и по переданным признакам сразу, а вместе с family по одному выбранному семейству и по ним же, поэтому сочетание family и verbs выборку расширяет, а не сужает. Найденное по своим признакам выделяется в отдельную группу «Свои признаки, переданные в вызове» и платформенным семействам не приписывается. Признаки ищутся буквально, принимается не больше двадцати штук длиной до 64 символов, а о том, сколько признаков отброшено и по какой причине, сказано в примечании. Когда заданы и family, и verbs, число найденных строк посчитано по семейству вместе со своими признаками, и это тоже названо в примечании.

Поиск признаков в коде идёт по индексу зарегистрированной базы, поэтому при явно заданном dump_path индекса нет и раздел не заполняется. В этом случае инструмент прямо называет причину, будь то отсутствие индекса, незавершённое построение или ошибка построения, вместо того чтобы показать пустой список как достоверный результат.

Параметры

  • dump_path: путь к каталогу выгрузки (содержит ExchangePlans/); абсолютный путь только к зарегистрированной базе, относительный только внутри настроенного корневого каталога сравнения
  • plan: опциональный фильтр, показать только план обмена с этим именем
  • mode: режим работы, plan (по умолчанию), diff или map (v2.30.0)
  • dump_path_b: вторая выгрузка для mode: "diff", разрешается по тем же правилам, что и dump_path (v2.30.0)
  • plan_b: второй план для mode: "diff" в пределах одной выгрузки; по умолчанию совпадает с plan (v2.30.0)
  • family: для mode: "map" оставить одно семейство признаков из семи перечисленных выше (v2.30.0)
  • verbs: для mode: "map" свои признаки, которые ищутся вместе с семействами, а не вместо них (v2.30.0)
  • format: формат вывода, text (по умолчанию) или json
  • base: имя базы, если подключено несколько; источник выгрузки при отсутствии dump_path

Границы: инструмент не подключается к живой базе и не показывает рантайм обмена. Таблицы регистрации изменений, список и состояние узлов, номера сообщений, очередь ошибок и конфликты РИБ вне области, потому что их нет в выгрузке. Отсутствие Content.xml это не пустой состав, а признак того, что отбор задаёт формат (планы на универсальном формате обмена). Файл Content.xml, который не удалось разобрать (или он слишком большой, или отклонён проверкой безопасности), даёт статус «состав неизвестен» и не выдаётся за чистый. Найденный в коде признак обмена говорит о том, что конструкция встречается в модуле, а не о том, что она выполняется.

Требует: выгрузку конфигурации, зарегистрированную флагом --dump, либо относительный путь внутри каталога, заданного флагом --exchange-compare-root

exchange_drops (v2.30.0)

Профессиональная

Осмотр каталогов файлового обмена 1С

Показывает, что лежит в каталоге файлового обмена: имена, размеры, даты изменения и возраст файлов. Отвечает на вопрос, идёт ли файловый обмен и как давно там лежат файлы, без подключения к базе и без расширения 1С, поэтому годится и там, где база недоступна.

Содержимое файлов инструмент не читает: сообщения обмена это данные клиента, и он берёт только то, что отдаёт lstat, то есть имя, размер, дату изменения и признак каталога или ссылки. Абсолютный путь к настроенному каталогу в ответ не попадает, имена показываются относительно него.

Вывода о том, завис обмен или нет, инструмент не делает, потому что файл возрастом сорок дней может означать и остановленный обмен, и архив, который никто не чистит. Возраст самого старого файла выдаётся как факт, а stale_after_minutes даёт число файлов старше порога, то есть счётчик, а не оценку.

Каталог задаёт администратор флагом --exchange-drop-root или переменной окружения MCP_1C_EXCHANGE_DROP_ROOT. Пока каталог не настроен, инструмент вообще не регистрируется и не появляется в списке инструментов, так что AI-ассистент его не увидит.

Параметры:

  • subdir: относительный подкаталог внутри настроенного каталога обмена; абсолютный путь не принимается
  • stale_after_minutes: порог в минутах, добавляет в ответ число файлов старше порога (по умолчанию 0). При нулевом пороге в текстовом ответе счётчика нет, а в формате json поля stale_after_minutes и stale_count присутствуют всегда и равны нулю
  • max_entries: предел числа показанных записей, 0 означает значение по умолчанию 500; запрошенное значение свыше 200000 уменьшается до предела, о чём говорится в примечании
  • max_depth: предел вложенности обхода, 0 означает значение по умолчанию 2; запрошенное значение свыше 64 уменьшается до предела, о чём говорится в примечании
  • format: формат вывода, text (по умолчанию) или json

Верхние границы max_entries и max_depth объявлены ещё и в схеме инструмента (200000 и 64), поэтому клиент, который сверяет аргументы со схемой, откажет в вызове со слишком большим значением до отправки, и уменьшения с примечанием вы не увидите. Само уменьшение работает у клиентов, которые схему не проверяют.

Обход ограничен по числу записей и по вложенности, и оба предела сообщаются в ответе. Встреченная при обходе символьная ссылка показывается, но внутрь неё обход не идёт; ссылка, названная в subdir, раскрывается, и обход идёт по каталогу назначения, если он остаётся внутри настроенного каталога.

Когда обход был усечён, потому что достигнут предел числа записей, достигнут предел вложенности или подкаталог не удалось прочитать, возраст самого старого файла и счётчик устаревших посчитаны только по показанным записям. В текстовом выводе это видно прямо в строках, которые превращаются в «самый старый файл среди показанных» и «файлов старше N мин среди показанных», а в примечании названо, каким параметром поднять предел. В формате json тот же факт несёт поле aggregates_partial.

Ответ в формате json содержит exists, список entries с полями name, is_dir, is_symlink, size, modified и age_seconds, признаки усечения capped, cap, depth_limited, depth и unreadable_subdirs, а также aggregates_partial, oldest_name, oldest_age_seconds, stale_after_minutes, stale_count и notes.

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

Требует: настроенный каталог обмена (--exchange-drop-root или MCP_1C_EXCHANGE_DROP_ROOT); без него инструмент отсутствует в списке

code_analyze → dependency_graph

Профессиональная

Граф зависимостей объектов

Визуализация связей между модулями конфигурации. Требует предварительного построения кэша командой --build-depgraph.

Параметры:

  • object (обязательный) - имя объекта метаданных для анализа зависимостей
  • direction - направление обхода: reverse (кто зависит от объекта), forward (от кого зависит объект), both
  • depth - глубина обхода графа (1-3)
  • format - формат вывода: text, json, mermaid
  • edge_types - оставить только связи указанных типов: movement, query, call, subscription и др. (по умолчанию все типы) (v2.22.0)
  • min_risk - оставить только связи с риском не ниже указанного: low, medium, high (помогает быстрее находить значимые зависимости в больших графах) (v2.22.0)
  • path_glob - ограничить анализ объектами, путь которых в выгрузке подходит под glob (поддерживает *, **, ?); удобно сузить граф до одной подсистемы или каталога (v2.23.0)

Учёт движений регистров полнее: помимо декларативных движений регистраторов учитываются и наборы записей, формируемые программно в коде (v2.22.0).

Имена объектов с выгрузок, созданных на macOS, корректно сопоставляются с узлами графа (нормализация Unicode NFD при загрузке) (v2.23.0).

Требует: --dump + --build-depgraph (предварительное построение кэша)

code_analyze → call_hierarchy

Профессиональная

Иерархия вызовов метода

Кто вызывает метод и кого вызывает он сам (callers/callees): трассировка на уровне методов по всей конфигурации. Помогает оценить влияние правки и проследить цепочки вызовов. Для зависимостей на уровне объектов метаданных используйте dependency_graph.

Параметры:

  • method (обязательный) - метод в форме Объект.Метод или Тип.Объект.Метод, например ОбщийМодуль.Расчёты.Пересчитать
  • direction - reverse (кто вызывает), forward (кого вызывает), both
  • depth - глубина обхода (по умолчанию 2)
  • format - text (дерево вызовов) или json

Результат неполный по дизайну: учитываются только квалифицированные вызовы вида Модуль.Метод(); вызовы без префикса и динамические (Выполнить/ЗапуститьМетод) не отражаются.

Требует: --dump + --build-depgraph (граф зависимостей)

code_analyze → arch_boundary (v2.22.0)

Профессиональная

Анализ нарушений границ подсистем (ARCH001)

Находит обращения к служебным общим модулям одной подсистемы из других подсистем, то есть использование внутренней реализации подсистемы в обход её публичного программного интерфейса. Помогает поддерживать чистую модульную архитектуру конфигурации. Анализ выполняется по запросу (опционально, по умолчанию выключен).

Параметры:

  • min_confidence - минимальная достоверность находок: high (по умолчанию, только точные нарушения) или medium (также вызовы широко используемых инфраструктурных служебных модулей)
  • limit - максимум находок в выводе (по умолчанию 100)
  • format - text (по умолчанию) или json

Анализ работает по дереву подсистем дампа: если в дампе нет подсистем, выводится явное уведомление, а не пустой результат.

Требует: --dump + --enable-depgraph (граф зависимостей)

code_analyze → find_modules (v2.23.0)

Профессиональная

Поиск модулей по пути и структурным фильтрам

Быстрый поиск файлов модулей по индексу путей выгрузки: по glob-шаблону пути или по структурным фильтрам. Помогает ориентироваться в большой конфигурации, не обходя полное дерево метаданных.

Параметры:

  • path_glob - glob по пути файла относительно корня выгрузки (поддерживает *, **, ?), например Documents/**/*.bsl
  • file_ext - фильтр по расширению файла, например .bsl (альтернатива path_glob)
  • category - фильтр по категории объекта (русское каноническое имя, например Документ)
  • module_type - фильтр по виду модуля, например МодульОбъекта, МодульМенеджера, МодульФормы
  • path_depth - фильтр по точной глубине пути (число сегментов)

В ответе возвращается не более 200 путей; общее число совпадений сообщается полностью.

Требует: --dump + --enable-depgraph (индекс путей)

code_analyze → graph_query (v2.23.0)

Профессиональная

Структурные запросы к графу зависимостей

Структурные запросы к графу зависимостей в формате JSON: ищите узлы и пути по шаблону, а не обходите граф от одного объекта. Работает на встроенном кэше графа, без внешних зависимостей.

Параметры:

  • query (обязательный) - объект запроса: match (узлы и рёбра), where (дополнительные условия), return с формой результата shape: rows, nodes, count, shortest_paths
  • format - формат вывода: json или text

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

Запрос ограничен по размеру (узлов до 6, рёбер до 5, глубина обхода до 3), это защищает от тяжёлых обходов и держит ответ компактным.

Требует: --dump + --enable-depgraph (граф зависимостей)

code_analyze → goto_definition (v2.25.0)

Профессиональная

Переход к объявлению метода

Место объявления процедуры или функции по выгрузке: модуль, строка, сигнатура и признак Экспорт. Разбор офлайн по выгрузке (--dump), живая база 1С не нужна.

Параметры:

  • method (обязательный) - метод в форме Объект.Метод или Тип.Объект.Метод, например ОбщийМодуль.Расчёты.Пересчитать
  • format - text или json

Разбор эвристический: анализируются объявления Процедура / Функция в модулях объекта из выгрузки. Динамически формируемые имена, переопределения в расширениях (&Вместо / &Перед / &После) и методы вне указанного объекта не отражаются.

Требует: --dump + --enable-depgraph

code_analyze → find_references (v2.25.0)

Профессиональная

Поиск мест вызова метода

Места вызова метода (кто вызывает): модуль, процедура, строка. Обход по обратным рёбрам графа вызовов из выгрузки, те же связи, что использует call_hierarchy в направлении «кто вызывает». Разбор офлайн по выгрузке (--dump).

Параметры:

  • method (обязательный) - метод в форме Объект.Метод или Тип.Объект.Метод, например ОбщийМодуль.Расчёты.Пересчитать
  • format - text или json
  • path_glob - ограничить поиск объектами, путь которых в выгрузке подходит под glob (поддерживает *, **, ?)

Результат неполный по дизайну: учитываются только квалифицированные вызовы вида Модуль.Метод(); вызовы без префикса и динамические не отражаются.

Требует: --dump + --enable-depgraph

code_read → dossier

Профессиональная

Полное досье объекта одним вызовом

Структура + где используется (used_by) + движения по регистрам (movements) + связанные объекты (related) одним вызовом. Богаче, чем context: значения перечислений и граф связей. Для лёгкого обзора достаточно context.

Параметры:

  • object_type + object_name (обязательны) - тип и имя объекта
  • depth - глубина графа связей (по умолчанию 1)
  • sections - подмножество секций досье (структура, used_by, movements, related)
  • format - markdown или json

При отсутствии графа зависимостей возвращается только структура объекта (degraded-режим).

Требует: --dump + --enable-depgraph (для секций графа)

code_read → report_structure (v2.25.0)

Профессиональная

Структура схемы компоновки данных (СКД) отчёта

Структура схемы компоновки данных отчёта из выгрузки: наборы данных (запрос, объект, объединение), параметры и наблюдаемые поля. Анализ read-only, по выгрузке (--dump), живая база 1С не нужна.

Параметры:

  • object_name - имя отчёта; если не указано, возвращается список отчётов, у которых есть схема компоновки
  • template - подстрока пути макета, если у отчёта несколько схем компоновки (.dcs); по умолчанию выбирается основная DataCompositionSchema.xml
  • format - формат вывода: markdown (по умолчанию) или json
  • base - имя базы, если подключено несколько

Требует: --dump

Профессиональная

Поиск по схемам компоновки данных отчётов

Поиск по схемам компоновки данных всех отчётов выгрузки: найти отчёты по имени набора, поля, параметра или ресурса, не открывая каждую схему вручную. Анализ read-only, по выгрузке (--dump).

Параметры:

  • filter (обязательный) - строка поиска по схемам компоновки данных отчётов
  • search_in - область поиска: dataset, field, parameter, resource или all (по умолчанию all); resource ищет среди полей набора данных
  • format - формат вывода: markdown (по умолчанию) или json
  • base - имя базы, если подключено несколько

Требует: --dump

Профессиональная

Семантический поиск по коду

Устаревший вариант: используйте code_search action=text mode=semantic. Прежний action=semantic будет полностью удалён в одной из будущих мажорных версий.

Поиск по смыслу, а не по тексту. Находит связанный код даже если названия отличаются. Требует флага --enable-semantic при запуске.

Режимы:

  • mode: "semantic" - чистый векторный поиск
  • mode: "hybrid" - комбинация BM25 + векторный поиск для максимальной точности

Требует: --dump + --enable-semantic

Архитектурная визуализация

Профессиональная

Mermaid-диаграммы архитектуры конфигурации

Команда --build-archviz строит Mermaid-диаграммы трёх уровней архитектуры: иерархия подсистем и их вложенность, связи документов с регистрами накопления, сведений и бухгалтерии, бизнес-процессы с точками маршрута и BSL-обработчиками.

Опционально диаграммы экспортируются в SVG или JSON. Поддерживается фильтрация по конкретной подсистеме или категории объектов, ограничение количества узлов и пакетный экспорт всех режимов сразу.

Пример запуска:

mcp-1c-pro --build-archviz --arch-viz all --output-dir ./diagrams --dump /path/to/dump

Параметры:

  • --build-archviz запустить генерацию диаграмм и выйти
  • --arch-viz режим: subsystems, doc-reg, bp или all
  • --output-format формат: mermaid, svg или json (по умолчанию mermaid)
  • --output-dir каталог для записи файлов (обязателен при --arch-viz all)
  • --filter-subsystem ограничить рамки одной подсистемой (рекурсивно по вложенным)
  • --filter-category ограничить тип объектов (Документ, РегистрНакопления и т. п.)
  • --max-nodes максимум узлов на диаграмме (по умолчанию 100)
  • --show-handlers показывать BSL-обработчики на диаграммах бизнес-процессов (по умолчанию включено)

При ответе свыше 1 MiB (env MCP_ARCHVIZ_BUDGET_BYTES) сервер сохраняет артефакт в локальный кэш и возвращает manifest {path, size_bytes, sha256, mime_type}, а AI-клиент читает файл напрямую.

Действия MCP-сервера:

  • action: "generate" Профессиональная - построить или обновить кэш диаграмм (подсистемы, Документ-Регистр, бизнес-процессы, JSON)
  • action: "get_subsystems" Профессиональная - Mermaid-диаграмма иерархии подсистем
  • action: "get_doc_reg" Профессиональная - Mermaid-диаграмма «Документ → Регистр»
  • action: "get_bp" Профессиональная - Mermaid-диаграммы бизнес-процессов
  • action: "get_json" Профессиональная - JSON-граф архитектуры

Требует: --dump

Настройка LLM провайдера

Профессиональная

Учётные данные YandexGPT или GigaChat для LLM-функций

Четыре функциональности Профессиональной редакции используют внешние LLM API для обогащения результатов: Автогенерация документации (--build-autodoc), Генерация тестов (--build-testgen), Генерация .epf обработок (--build-epfgen) и Навигация по типовым конфигурациям (--build-typicalconfigs). В режиме MCP-сервера к LLM обращается только инструмент автогенерации документации: генерация тестов, генерация .epf и навигация по типовым в этом режиме к LLM не обращаются.

Поддерживаются два провайдера: YandexGPT (по умолчанию, выбирается флагом --autodoc-provider yandexgpt) и GigaChat (--autodoc-provider gigachat). Учётные данные читаются из переменных окружения и должны быть заданы до запуска.

Переменные окружения:

# YandexGPT (по умолчанию)
export YANDEXGPT_API_KEY=AQVN...
export YANDEXGPT_FOLDER_ID=b1g...

# GigaChat
export GIGACHAT_CLIENT_ID=...
export GIGACHAT_CLIENT_SECRET=...

Где взять учётные данные:

  • YandexGPT сервисный аккаунт Yandex Cloud с ролью ai.languageModels.user, API-ключ выпускается в консоли Yandex Cloud, идентификатор каталога указан там же на странице каталога
  • GigaChat регистрация в портале разработчика Сбера, после этого выпускаются Client ID и Client Secret для авторизации

Если переменные не заданы, --build-autodoc завершается с ошибкой вида --autodoc-provider=yandexgpt требует переменные окружения YANDEXGPT_API_KEY и YANDEXGPT_FOLDER_ID (или аналогично для GigaChat), --build-testgen и --build-epfgen печатают предупреждение и продолжают без LLM, --build-typicalconfigs тоже продолжает без LLM. В режиме MCP-сервера без переменных возвращают ошибку действия generate и regenerate инструмента автогенерации документации, а summary и find работают.

Запуск без LLM:

  • --testgen-llm-disable генерация только скелетов YAxUnit/Vanessa без LLM-комментариев
  • --epfgen-llm-disable генерация бандлов .epf без LLM-обогащения
  • --typicalconfigs-llm-disable индексация подсистем без описаний (Markdown-файлы будут пустыми)
  • У --build-autodoc отдельного флага отключения LLM нет: автогенерация документации полностью построена на ответах модели и без API-ключей не запускается

Автогенерация документации

Профессиональная

Markdown-описания объектов через YandexGPT или GigaChat

Команда --build-autodoc формирует отдельный Markdown-файл для каждого объекта конфигурации с описанием назначения, реквизитов, табличных частей и связей с другими объектами.

Поддерживаются провайдеры YandexGPT и GigaChat. Результаты кэшируются: повторный запуск регенерирует только изменившиеся объекты, если не задан --autodoc-regen.

Пример запуска:

mcp-1c-pro --build-autodoc --dump /path/to/dump --autodoc-out ./docs/auto --autodoc-provider yandexgpt

Параметры:

  • --build-autodoc запустить генерацию документации и выйти
  • --autodoc-out каталог для autodoc Markdown-файлов (по умолчанию docs/auto)
  • --autodoc-provider LLM-провайдер: yandexgpt или gigachat
  • --autodoc-model модель провайдера (например, yandexgpt-lite)
  • --autodoc-kinds виды объектов через запятую: all либо Document,Catalog,AccumulationRegister,InformationRegister,Report,DataProcessor
  • --autodoc-regen игнорировать кэш и перегенерировать все объекты
  • --autodoc-concurrency размер пула воркеров (по умолчанию 4)
  • --autodoc-max-input-tokens лимит входных токенов на объект (модуль усекается, по умолчанию 6000)
  • --autodoc-rps лимит запросов в секунду к LLM-провайдеру (по умолчанию 5.0)

При ответе свыше 1 MiB (env MCP_AUTODOC_BUDGET_BYTES) сервер сохраняет артефакт в локальный кэш и возвращает manifest {path, size_bytes, sha256, mime_type}, а AI-клиент читает файл напрямую.

Действия MCP-сервера:

  • action: "generate" Профессиональная - сгенерировать Markdown-документацию через LLM (нужен настроенный провайдер)
  • action: "regenerate" Профессиональная - перегенерировать всё, игнорируя кэш
  • action: "summary" Профессиональная - сводка по сгенерированным файлам
  • action: "find" Профессиональная - найти Markdown-файл по имени объекта

Требует: --dump; действиям generate и regenerate ещё нужен API-ключ выбранного LLM-провайдера, summary и find работают без него (см. Настройка LLM провайдера)

Генерация тестов

Профессиональная

Автоматическая генерация YAxUnit и Vanessa-тестов

Команда --build-testgen анализирует BSL-модули конфигурации и формирует scaffold-тесты YAxUnit для экспортированных процедур и функций (правила TG001-TG019), Vanessa .feature сценарии для taint-находок с критичностью CVSS не ниже Medium (правило TG020), а также файл manifest.json с итогами прогона.

Доступна как разовая генерация (--build-testgen) либо в режиме MCP-сервера (--enable-testgen) для интерактивных запросов от AI-ассистента.

Пример запуска:

mcp-1c-pro --build-testgen --dump /path/to/dump --testgen-framework auto --testgen-output ./tests

Параметры:

  • --build-testgen запустить разовую генерацию тестов и выйти
  • --enable-testgen включить testgen в режиме MCP-сервера
  • --testgen-output каталог для записи тестовых файлов (по умолчанию <dump>/.testgen-output)
  • --testgen-framework фреймворк: yaxunit, vanessa, both или auto (выбирается по типу объекта)
  • --testgen-rules подмножество правил TG001..TG020 через запятую
  • --testgen-regen игнорировать кэш и перегенерировать все тесты
  • --testgen-taint-regressions эмитировать Vanessa-регрессии по taint-находкам (правило TG020)
  • --testgen-include-bsp генерировать тесты для модулей БСП/SSL
  • --testgen-concurrency число параллельных воркеров (по умолчанию min(CPU, 8))
  • --testgen-llm-disable отключить обогащение через LLM (работает без API-ключей)
  • --testgen-emit-sarif путь для SARIF 2.1.0 отчёта по testgen
  • --testgen-audit-trail путь к audit log testgen (по умолчанию <dump>/.testgen-audit.log)
  • --testgen-vendor-baseline путь к vendor-baseline дампу для фильтрации стандартных модулей

Действия MCP-сервера (--enable-testgen):

  • action: "generate" Профессиональная - генерация тестов по всей кодовой базе (нужен dump_path)
  • action: "summary" Профессиональная - сводка: число тестов, покрытие, ошибки
  • action: "findings" Профессиональная - список сгенерированных тестов (с фильтрами)
  • action: "manifest" Профессиональная - прочитать manifest.json последней генерации

Требует: --dump. Ключ LLM-провайдера не обязателен: разовый прогон --build-testgen без него идёт без обогащения через LLM, а в режиме MCP-сервера генерация к LLM не обращается вовсе (см. Настройка LLM провайдера)

Генерация .epf обработок

Профессиональная

Designer-compatible XML+BSL бандлы внешних обработок 1С

Команда --build-epfgen формирует Designer-compatible XML+BSL бандлы для всех 6 видов внешних обработок 1С: ПечатнаяФорма, ЗаполнениеОбъекта, СозданиеСвязанныхОбъектов, Отчет, ДополнительнаяОбработка, ДополнительныйОтчет. Каждый бандл соответствует БСП-контракту и готов к загрузке Конфигуратором.

Опционально формируются скрипты pack.cmd / pack.sh для сборки бинарного .epf. В config-aware режиме при наличии Configuration.xml LLM может предлагать имена реквизитов, согласованные с метаданными целевой конфигурации.

Доступна как разовая генерация (--build-epfgen) либо в режиме MCP-сервера (--enable-epfgen) для интерактивных запросов от AI-ассистента.

Пример запуска:

mcp-1c-pro --build-epfgen --epfgen-spec ./bundles.yaml --epfgen-pack

Параметры:

  • --build-epfgen запустить разовую генерацию бандлов и выйти
  • --enable-epfgen включить epfgen в режиме MCP-сервера
  • --epfgen-spec путь к YAML/JSON-файлу со списком бандлов (обязательный для --build-epfgen)
  • --epfgen-output каталог для записи бандлов и manifest.json
  • --epfgen-config-path путь к Configuration.xml для config-aware режима
  • --epfgen-regen игнорировать кэш и перегенерировать все бандлы
  • --epfgen-pack дополнительно генерировать pack.cmd / pack.sh для сборки .epf через Конфигуратор
  • --epfgen-emit-tests эмитировать sibling YAxUnit-тесты через testgen API
  • --epfgen-suggest-attrs LLM-подсказки имён реквизитов (требует config-aware + LLM)
  • --epfgen-concurrency число параллельных воркеров (по умолчанию min(CPU, 8))
  • --epfgen-llm-disable отключить обогащение через LLM (работает без API-ключей)
  • --epfgen-emit-sarif путь для SARIF 2.1.0 отчёта
  • --epfgen-audit-trail путь к epfgen audit log
  • --epfgen-platform-version целевая версия 1С (по умолчанию 8.3.10); контролирует версию формата MDClasses XML

Параметр rule_id (в YAML/JSON-спецификации бандла, а также в MCP-вызове epfgen.generate) принимает идентификаторы из набора EG001-EG020 (полный список встроенных правил).

Изменения спецификации бандла в v2.30.0

Два параметра элемента specs теперь объявлены в схеме инструмента, поэтому AI-ассистент их видит и может осмысленно заполнить. Параметр form_name задаёт имя управляемой формы для тех видов обработок, которые её требуют, и по умолчанию это Главная; пустое значение отключает выпуск формы для правил, допускающих вариант без неё. Параметр print_template_name задаёт имя макета печати и влияет на выбор правила для вида ПечатнаяФорма.

Имена name и form_name теперь проверяются по правилам имён объектов 1С: допустимы буквы, цифры и подчёркивание, не более 80 символов, а пробелы, точки и разделители пути отклоняются. Пустое имя бандла тоже стало ошибкой, тогда как раньше оно давало файл с именем вида DataProcessor..xml. Спецификации, где имя содержит точку или пробел, придётся поправить.

Ключи элемента specs, которых нет в схеме, теперь отбрасываются. Прежде они доходили до генератора, хотя ни один клиент не мог узнать о них из схемы, и меняли содержимое обработки. Вызов по-прежнему выполняется успешно и сообщения об ошибке не возвращает, но такой ключ больше ни на что не влияет, поэтому обработка соберётся со значениями по умолчанию. Проверьте свои вызовы на vid, safe_mode, permissions, platform_version, output_table, skd_scheme, empty_form, has_form, output_pdf, bsp_version, no_form, minimal, print_template_kind, wizard_pages и import_format. Вместо vid пользуйтесь объявленным kind, он работает как прежде, а остальные параметры остаются доступны в файле спецификации при разовом запуске --build-epfgen. Отдельно обратите внимание на safe_mode: обработка, для которой безопасный режим отключали через MCP-вызов, теперь генерируется с включённым безопасным режимом.

Каталог output_dir должен быть каталогом выгрузки зарегистрированной базы или его подкаталогом, как описано в разделе Пути к выгрузкам. Собственный флаг оператора --epfgen-output под это ограничение не подпадает, а документированное значение по умолчанию <текущий каталог>/.epfgen-output теперь работает и в режиме MCP-сервера, а не только в разовом запуске. Ответ действия generate больше не заканчивается абсолютным путём к manifest.json.

Действия MCP-сервера (--enable-epfgen):

  • action: "generate" Профессиональная - генерация .epf-бандлов по спецификации
  • action: "summary" Профессиональная - сводка последней сборки
  • action: "findings" Профессиональная - постраничный список результатов по бандлам
  • action: "manifest" Профессиональная - прочитать manifest.json последней сборки
  • action: "validate" Профессиональная - разбор спецификаций без эмиссии файлов

Требует: --epfgen-spec для разовой генерации. Ключ LLM-провайдера не обязателен: разовая генерация без него идёт без обогащения через LLM, а в режиме MCP-сервера сборка к LLM не обращается вовсе (см. Настройка LLM провайдера)

Навигация по типовым конфигурациям

Профессиональная

Автоматическая классификация семейства типовой и индекс подсистема ↔ объект

Команда --build-typicalconfigs определяет семейство типовой конфигурации по сигнатурам метаданных и строит двусторонний индекс подсистема ↔ объект для AI-навигации. Поддерживается распознавание основных линеек: Бухгалтерия предприятия 3.0, Зарплата и управление персоналом 3.1, Управление торговлей 11, Розница, Комплексная автоматизация и ERP.

Объекты классифицируются по правилам TC001-TC020 на shared (БСП/SSL), bp_specific, zup_specific, ut_specific и retail_specific. Поверх классификации детектируются кастомные доработки заказчика поверх типовой конфигурации.

В результате формируется набор артефактов: index.json (подсистема → объекты), reverse.json (объект → подсистемы), manifest.json с метаданными о версии платформы и обнаруженном семействе, а также по одному .md файлу на каждую подсистему с LLM-обогащённым описанием.

В режиме MCP-сервера (--enable-typicalconfigs) AI-ассистент получает доступ к единому tool typicalconfigs с действиями detect (определить семейство), subsystems (список подсистем), lookup (найти объект по имени), reverse_lookup (из объекта в подсистемы) и extension_points (точки расширения).

Пример запуска (разовая индексация):

mcp-1c-pro --build-typicalconfigs --typicalconfigs-dump-path ./dump --typicalconfigs-output ./typicalconfigs-output --typicalconfigs-llm-disable

Пример запуска (MCP-сервер с включённой навигацией):

mcp-1c-pro --enable-typicalconfigs --base main=https://erp.example.com/erp/hs/mcp-1c --dump main=./dump

Параметры:

  • --build-typicalconfigs запустить разовую индексацию и выйти
  • --enable-typicalconfigs включить typicalconfigs в режиме MCP-сервера
  • --typicalconfigs-output каталог для index.json, reverse.json, manifest.json и per-subsystem .md файлов
  • --typicalconfigs-dump-path путь к dump-каталогу (обязателен при --build-typicalconfigs)
  • --typicalconfigs-regen игнорировать кэш и регенерировать индекс
  • --typicalconfigs-llm-disable отключить обогащение через LLM (описания подсистем останутся пустыми)
  • --typicalconfigs-concurrency размер пула воркеров (по умолчанию min(CPU, 8), значение 0 означает auto)
  • --typicalconfigs-emit-sarif путь для SARIF 2.1.0 отчёта
  • --typicalconfigs-audit-trail путь к audit log по операциям typicalconfigs
  • --typicalconfigs-max-subsystems cap для очень больших дампов (по умолчанию 500); подсистемы свыше cap получают статус truncated
  • --typicalconfigs-platform-version целевая версия 1С (по умолчанию 8.3.10)

Требует: --typicalconfigs-dump-path для разовой индексации. Ключ LLM-провайдера не обязателен: разовая индексация без него идёт без обогащения через LLM, а в режиме MCP-сервера навигация к LLM не обращается (см. Настройка LLM провайдера)

С версии v2.30.0 параметр dump_path в MCP-вызове должен указывать на каталог выгрузки зарегистрированной базы или его подкаталог, как описано в разделе Пути к выгрузкам; собственный флаг оператора --typicalconfigs-output под это ограничение не подпадает. Тогда же изменилось действие параметра regen в MCP-вызове: он больше не удаляет каталог .cache/typicalconfigs целиком, а убирает внутри него только файл archviz.json, поэтому посторонние файлы, если вы их там держали, теперь переживают регенерацию.

Подавление проверок прагмами typconf:ignore

Чтобы выборочно отключить классификацию или проверки typicalconfigs на уровне отдельной строки или процедуры, используйте комментарии-прагмы в BSL-коде:

// Отключить проверку для конкретной строки:
ВыполнитьСлужебнуюЛогику(); // typconf:ignore

// Отключить проверки в пределах процедуры целиком:
Процедура КастомнаяОбработка() Экспорт
    // typconf:ignore
    // ...тело процедуры...
КонецПроцедуры

Прагма typconf:ignore действует только в области, где она объявлена (на текущей строке или в текущей процедуре) и не отключает классификацию объекта в целом.

code_review: ревью расширений

Профессиональная

Консолидированный инструмент с тремя действиями: review_extension (CFEDiff, структурный diff двух версий .cfe), base_vs_ext (сверка основной конфигурации с расширением) и ext_vs_release (проверка расширения перед новым релизом поставщика)

Точность и полнота сравнения повышены (v2.19.0): в результатах меньше нераспознанных объектов.

review_extension: структурный diff двух версий расширения .cfe

Замена ручному diff или git-diff бинарных .cfe (которые показывают только «файл изменён»). CFEDiff распаковывает оба расширения, разбирает структуру и выдаёт Markdown-отчёт с детальным сравнением BSL-кода, форм и метаданных.

Для кого:

  • 1С-разработчики, работающие с расширениями типовых конфигураций (yaxunit, BIA-Standard и т. д.)
  • DevOps-команды с CI/CD pipeline для расширений
  • Team leads на code review для PR с изменениями .cfe

Способ 1. Через Claude Code (MCP-инструмент)

В режиме MCP-сервера действие code_review.review_extension принимает пути к двум .cfe и возвращает Markdown-отчёт прямо в чате.

Пример вызова:

{
  "action": "review_extension",
  "base_path": "/repo/master/MyExt.cfe",
  "head_path": "/repo/feature/MyExt.cfe",
  "format": "markdown"
}

Способ 2. CLI для CI и pre-commit

Подкоманда review бинарника mcp-1c-pro запускается из CI или git-hook:

mcp-1c-pro review --format markdown -o diff.md base.cfe head.cfe
echo "exit code: $?"

Флаги review ставятся перед файлами: разбор флагов останавливается на первом имени файла. Код выхода: 0, если различий нет, и 1, если в отчёте есть добавленный, удалённый или изменённый объект. С версии 2.41.0 изменённым объект бывает и тогда, когда его содержимое на вид то же: те же байты иначе разложены по потокам, на одной стороне есть лишний пустой поток или несколько записей контейнера дают объекту один поток с разными байтами. Файлы, равные байт в байт, дают 0. Код 1 бывает и при ошибке во флаге, стоящем перед файлами, например при неизвестном флаге или не числе в --max-bytes. Прочие ошибки дают 2: например, передано не два файла, в том числе когда флаг стоит после файлов, или у --format неподдерживаемое значение. Запуск с --bug-report отчёт не строит, поэтому значение --format в нём не проверяется. Успешный запуск с --bug-report и вызов --help завершаются с кодом 0. Строка с echo в примере написана для bash.

На машине, где запускается review, в том числе на раннере CI, нужна действующая лицензия Профессиональной версии, порядок активации описан в разделе Активация платной версии: без неё сравнение не выполняется и команда завершается с кодом 2. Флаги и число файлов проверяются раньше лицензии, поэтому --help и без лицензии даёт 0, а ошибка во флаге перед файлами даёт 1. Ключ рассчитан на одну машину: активация на раннере переносит ключ туда, и если с тем же ключом работает сервер разработчика, он может остаться без платных инструментов или забрать ключ обратно. Частые активации сервер лицензий может отклонить; что делать при отказе, описано в разделе Если активация не прошла.

Подходит для:

  • pre-commit hook: команда возвращает 1 при любом различии, которое осталось после фильтров --ignore-* (часть из них включена по умолчанию), порога у неё нет
  • GitHub Actions / GitLab CI: отчёт пишется в файл из -o, комментарий к PR из него делает уже отдельный шаг конвейера
  • daily backup-diff: что изменилось со вчера

Пример workflow GitHub Actions с разбором кодов выхода есть в статье Сравнение расширений 1С (.cfe), в разделе «Как встроить в CI и pre-commit?».

Опциональные флаги

  • --format markdown|json|text формат вывода (по умолчанию markdown)
  • --ignore-* (11 флагов) фильтры технического шума: trailing whitespace, line endings, BOM, UUID-порядок и т. д.
  • --no-watermark убрать подпись оплаченной лицензии; подпись Trial флаг не убирает, подробнее в разделе «Лицензирование» ниже
  • --diagnostic добавить диагностический zip-пакет (для тикетов поддержки)
  • --bug-report PII-safe tar.gz для GitHub-issue submission
  • --enable-ibcmd рекомендательная сверка через ibcmd (8.3.27+, опционально)

Что внутри Markdown-отчёта

# CFEDiff
**Base:** path/to/base.cfe (SHA-256 ...)
**Head:** path/to/head.cfe (SHA-256 ...)

## Сводка
- Добавлено: 8 объектов
- Удалено:   1 объект
- Изменено:  9 объектов
- BSL-строк (+/-): 7065 / 238

## Изменённые объекты

### CommonModule РГП_ГлобальныйПоискВызовСервера
@@ -1,20 +1,122 @@
+// @skip-check bsl-legacy-check-pragma-for-unused-method - Баг ЕДТ
 #Область ОбработчикиСобытий
 ...

## Активные фильтры
- IgnoreTrailingWhitespace
- IgnoreLineEndings
...

Поддерживаемые форматы экспорта

CFEDiff умеет читать оба формата:

  • Canonical Designer экспорт через 1С Designer DESIGNER /DumpCfg (8.3.x)
  • ibcmd-Mac/Linux экспорт через ibcmd config export (8.3.27+)

Лицензирование

  • Подпись Trial «Generated by CFEDiff Trial. License expires …» в отчёте команды review стоит у пробного ключа на 14 дней весь его срок. Флаг --no-watermark её не убирает
  • Подпись оплаченной лицензии «Сформировано лицензией …» в отчёте команды review по умолчанию выключена и появляется, только если её включает переменная окружения MCP_1C_WATERMARK_ENABLED (например, со значением true). Флаг --no-watermark убирает только эту подпись
  • В режиме MCP-сервера (code_review, действия review_extension, base_vs_ext и ext_vs_release) подписи Trial нет, а подпись оплаченной лицензии может появиться, только если сервер запущен с включённой MCP_1C_WATERMARK_ENABLED, и снимается параметром no_watermark
  • Расширенная (без Профессиональной) запуск review вернёт subcommand requires Pro edition + exit 2

Текущие ограничения

  • Формы сравниваются структурно, только если поток формы лежит в контейнере под ключом form/Form.0: тогда видны реквизиты, элементы с их свойствами и обработчики. Если форма лежит в записи объекта вместе с модулем формы, она сравнивается по байтам: отчёт сообщает только о различии байтов, без структурного сравнения.
  • Метаданные объекта: читаются только имя и вид. Изменение синонима, свойств или состава видно лишь как отличие байтов; с версии 2.41.0 это отличие названо и у объекта, для которого показан дифф модуля. Реквизиты и табличные части по имени не сравниваются.
  • Опциональная сверка через ibcmd (флаг --enable-ibcmd, по умолчанию выключена) это рекомендательная сверка через официальную утилиту ibcmd: она выгружает обе версии расширения и сравнивает, какие объекты изменились по этой выгрузке и по основному diff, среди объектов тех видов, которые основной diff назвал по имени. С версии 2.41.0 переименованный объект входит в сравнение под старым и новым именем. Если наборы совпали, предупреждения нет, если разошлись, приходит предупреждение IBCMD_VALIDATION_FAILED. С той же версии расхождением считается и прогон, где основной diff не назвал по имени ни одного изменённого объекта, а ibcmd изменённые объекты назвал. Если утилиты нет или выгрузка не удалась, сверка пропускается с предупреждением IBCMD_NOT_AVAILABLE. Результат diff от неё не зависит и не блокируется (exit code не меняется).
  • Имена объектов: объект, имя которого не читается из заголовка его метаданных, показан под UUID. С версии 2.41.0 объект с тем же UUID и другим именем, если имя прочитано на обеих сторонах, показан одной записью с обоими именами и пометкой «(переименован)».

ext_vs_release: проверка расширения перед новым релизом поставщика (v2.42.0)

Действие code_review.ext_vs_release показывает, какие изменения нового релиза поставщика затрагивают объекты расширения, включая изменения модулей и поддерживаемых элементов форм. Передайте расширение в ext_dump как каталог XML-выгрузки или файл .cfe, а новую версию конфигурации той же поставки, что установлена в текущей базе, в release_dump как каталог XML-выгрузки. Для каталога расширения ibcmd не нужен; для чтения файла .cfe серверу требуется ibcmd платформы 1С.

Параметры:

  • ext_dump (обязательный) - файл .cfe расширения или каталог его XML-выгрузки
  • release_dump (обязательный) - каталог XML-выгрузки нового релиза основной конфигурации
  • base - имя зарегистрированной базы, на которой установлено расширение; сервер берёт её выгрузку, заданную через --dump
  • base_dump - корень выгрузки этой базы или подкаталог; задайте его явно, если базу по имени не разрешаете
  • format - markdown (по умолчанию), json или text
  • ignore - карта фильтров с булевыми значениями; в этом действии поддерживаются только bsl_inline_whitespace (включён по умолчанию) и comments (выключен по умолчанию)
  • no_watermark: true - убрать строку атрибуции лицензии, если сервер настроен добавлять её через MCP_1C_WATERMARK_ENABLED; иначе параметр ничего не меняет

base и base_dump используют выгрузку на диске; инструмент не подключается к живой базе 1С и не выбирает базу по умолчанию. base_dump переопределяет путь выгрузки, разрешённый через base. Пути к выгрузкам ограничены каталогом зарегистрированной базы и его подкаталогами, как описано в разделе Пути к выгрузкам.

Отчёт проверяет, что целевой метод есть в новом релизе и его параметры совпадают с перехватом расширения. Если передана выгрузка текущей базы через base или base_dump, дополнительно сравнивается тело целевого метода в базе и в новом релизе. Без этой выгрузки тела целей перехватов &Перед, &После и &Вместо не сравниваются; наличие метода и совпадение параметров всё равно проверяются, а непроверенные места помечаются в отчёте.

base_vs_ext: сверка основной конфигурации с расширением

Действие code_review.base_vs_ext сравнивает основную конфигурацию (XML-дамп) с расширением (XML-дамп) и показывает: собственные объекты расширения с property-level составом и подписками; для заимствованных объектов: переопределённые свойства, добавленные реквизиты и табличные части, перехваты &Вместо / &ИзменениеИКонтроль относительно базы.

Параметры:

  • ext_dump (обязательный) - каталог XML-дампа расширения
  • base - имя зарегистрированной базы; сервер использует её выгрузку, заданную через --dump
  • base_dump - корень выгрузки зарегистрированной базы или подкаталог; без выгрузки базы сравниваются только собственные объекты расширения
  • format - markdown (по умолчанию), json или text

Доступно с v2.17.0.

С версии v2.30.0 каталоги ext_dump и base_dump должны быть каталогом выгрузки зарегистрированной базы или его подкаталогом, как описано в разделе Пути к выгрузкам. Это самое заметное ограничение из всех, потому что расширение обычно выгружают в рабочий каталог разработчика, а запуска из командной строки у этого действия нет. Если сверка перестала работать, зарегистрируйте каталог выгрузки расширения флагом --dump при запуске сервера. На действие review_extension это не распространяется: оно по-прежнему принимает произвольные пути к файлам .cfe.

Для заимствованного объекта отчёт перечисляет его формы, но действие не проверяет формы и их модули. Это ограничение относится и к объектам, для которых отчёт показывает другие найденные изменения.

«Второе мнение»: независимая сверка результатов сравнения

Необязательная рекомендательная проверка, которая не блокирует работу, а лишь обращает внимание на возможные расхождения. Независимо пересчитывает результат сравнения через официальную утилиту 1С ibcmd и сопоставляет его с основным результатом.

Возможность командной строки. Включается флагом перед файлами:

  • mcp-1c-pro review --enable-ibcmd <base.cfe> <head.cfe>

Утилита ibcmd ищется в трёх местах по порядку: по значению переменной окружения MCP_1C_IBCMD_PATH, если она задана; затем по имени ibcmd в каталогах PATH; затем в известных каталогах установки платформы 1С. Третий шаг добавлен в версии 2.33.0, до неё просматривались только первые два. Если утилита не найдена, сверка пропускается, а обычное сравнение конфигураций работает как всегда.

Доступно с v2.19.0. Только в командной строке.

Цена: см. тарифы для актуальной стоимости лицензии Профессиональной редакции.

Подкоманда review. Требует лицензию Профессиональной редакции или пробную лицензию.

Назад Инструменты Расширенной версии