Эта категория про проверку BSL-кода после изменений: LSP diagnostics, статический анализ, проверка в EDT, syntax-check и review фрагментов через 1С:Напарник.
Инструменты этой категории помогают проверять BSL-код после изменений: синтаксис, статический анализ, диагностику через LSP, проверку в EDT, сборку, тесты и ревью фрагментов. Они нужны, чтобы агент не только написал код, но и довел изменение до проверяемого результата.
В сравнении ниже разделены локальные анализаторы, LSP-обертки, проверки через EDT или Конфигуратор, тестовые инструменты и сервисы ревью кода.
| Критерий | Что сравнивается |
|---|---|
| Движок проверки | Собственный анализатор, BSL Language Server, EDT, Конфигуратор 1С, 1С:Напарник или закрытый продукт |
| Область проверки | Весь проект, каталог, файл, модуль, конфигурация, отдельный фрагмент кода |
| Тип результата | Структурированные диагностики, SARIF/JSONL, LSP diagnostics, текстовый ответ, отчет тестового/сборочного запуска |
| Глубина проверки | Только синтаксис, статический анализ, правила качества, review логики/производительности, сборочная проверка |
| Исправления | Code actions, форматирование, генерация исправленного кода или только отчет |
| Интеграция с агентом | Прямой MCP tool, MCP-bridge к LSP/EDT, Claude Code plugin, desktop shell или платный внешний сервер |
| Прозрачность реализации | Открыта ли реализация проверки; если кода нет, сравнение ограничено публичным описанием |
| Набор инструментов | Движок проверки | Область | Синтаксис | Статический анализ | Review логики/стиля | Исправления | Формат результата |
|---|---|---|---|---|---|---|---|
| внешний анализатор; просмотр готового SARIF | локальный отчёт и связанные BSL-файлы | по отчёту | по отчёту | по отчёту | нет автоматических | SARIF 2.1.0 → дерево замечаний | |
| LLM-роли, Конфигуратор; внешний анализатор по настройке | BSL-файлы, diff и загружаемая конфигурация | Конфигуратор или внешний MCP | внешний сервер | роли ревью/архитектуры/производительности | отдельная роль исправления | отчёт роли, журналы Конфигуратора, diagnostics внешнего MCP | |
| чек-лист BSL и роль ревьюера Claude Code | локальные изменения проекта | внешние средства | внешние средства | 1c-code-reviewer + правила | агент в разрешённой области | текстовый отчёт агента | |
| BSL Language Server + локальные YAML-правила | переданный BSL-код | через BSL LS | диагностики и правила KB | kb.check_standards | bsl_ls.format возвращает текст | структурированные результаты | |
| BSL Language Server + локальный BSL-гейт | файл/каталог | да | да | правило БД в цикле | нет | текст диагностик, явное «0 файлов» | |
| собственный анализатор + LSP/CLI | проект/каталог/файл | да | да | нет | code actions через LSP; отчеты для CI | SARIF, JSONL, LSP diagnostics | |
| Python-движок onec-hbk-bsl | проект/каталог/файл/метод | да | да | ранжирование проблем и сложности | bsl_fix, bsl_format с предварительным просмотром | MCP JSON: диагностики, метрики, сводки | |
| собственный Python-анализатор и tree-sitter | проект/каталог/файл | да | 180 правил | нет отдельного review | bsl_fix, bsl_format, bsl_rename; CLI formatter | MCP JSON, CLI text/JSON/SARIF, LSP diagnostics | |
| проверка BSL по API платформы из .hbk и внешнему индексу символов | BSL-модуль или фрагмент | ограниченно: разбор процедур, функций и директив | да: API платформы и разрешённые пользовательские методы | нет | перестроение индекса символов | JSON с ошибками, строкой/колонкой и confidence | |
| внутренний адаптер анализа кода + проверки сборки/runtime | workspace/source set | да | да | частично через рабочий цикл | проверка после изменений | результат MCP-инструмента / вывод сборки | |
| BSL Language Server | файл/проектный LSP-инстанс | да | да | нет | нет в 1c-check | LSP diagnostics | |
| BSL Language Server через LSP bridge | файл/проект | да | да | нет | code actions | LSP diagnostics | |
| BSL Language Server JAR | каталог/файл | да | да | нет | форматирование | JSON + текстовая сводка | |
| 1C:EDT workspace diagnostics | EDT-проект/ресурс | да | да, в пределах EDT markers | нет | revalidate/clean как пересчет проверок | project errors / summary | |
| 1C:EDT workspace diagnostics | EDT-проект/запрос | да | да, через EDT validation | нет | нет в проверочной категории | validation errors / результат операции | |
| EDT CLI + Конфигуратор 1С | EDT-проект/конфигурация/модули | да | частично, как platform/EDT validation | нет | нет | результат check/build/test command | |
| Designer + EDT CLI + локальный runner | проект/конфигурация/модули | да | частично, как build/validate pipeline | нет | нет | структурированный runner/tool result | |
| EDT diagnostics + QA pipeline | EDT workspace/project | да | да, через EDT diagnostics | нет | проверка после изменений | diagnostics summary / QA status | |
| 1С:Напарник + syntax-checker direct mode; веб-чат с внешними MCP tools | фрагмент кода | да | нет как локальный статанализ | да | через отдельные edit/rewrite сценарии | текстовый ответ Напарника | |
| 1С:Напарник + syntax-checker direct mode | фрагмент кода | да | нет как локальный статанализ | да | rewrite/modify | текстовый ответ Напарника | |
| 1С:Напарник | фрагмент кода | да | нет как локальный статанализ | да | нет отдельного patch workflow | текстовый ответ Напарника | |
| 1С:Напарник | фрагмент кода или file_path | да | нет как локальный статанализ | да | нет отдельного patch workflow | текстовый ответ Напарника | |
| Claude Code LSP plugin + BSL Language Server | файлы в Claude Code | да | да | нет | code actions / quick fixes, formatting | LSP diagnostics внутри Claude Code | |
| Claude Code LSP plugin + внешний BSL Language Server | файлы в Claude Code | да | да | нет | зависит от LSP-клиента | LSP diagnostics внутри Claude Code | |
| встроенная интеграция BSL Language Server + LLM | текущий фрагмент/модуль в desktop UI | да | да, по диагностике BSL LS | да, для исправления ошибок | команда исправления по diagnostics | UI diagnostics + prompt context | |
| PerformanceStudio + SQL antipatterns + backend SDBL analyzer/BSL LS | SDBL-запрос или план MSSQL/PostgreSQL | только SDBL backend | да, для запросов/планов | AI explanation/rewrite | AI rewrite; рекомендации по плану/индексам | desktop UI / внутренний JSON-RPC | |
| BSL Language Server по описанию | фрагмент/код через сервер | да | да, если включены правила BSL LS | нет | нет | ответ tool | |
| 1С:Напарник | фрагмент кода | да | нет как локальный статанализ | да | rewrite/modify | текстовый ответ Напарника | |
| BSL Language Server в Docker | mounted source dir | да | да | нет | нет | diagnostics BSL LS | |
| ИИ-сервис + плагин EDT | фрагмент/проектный контекст | заявлено | неясно | да, как ИИ-проверка | через продукт/плагин EDT | текстовый ответ / не раскрыто | |
| база стандартов v8std.ru + диагностические страницы | короткий фрагмент/список диагностик | нет | нет | да, как объяснение стандартов и диагностик | нет | текстовые ссылки/страницы стандартов | |
| проверка путей реквизитов по метаданным 1С 7.7 | текст запроса/кода или путь реквизита | нет | нет | частично, только пути реквизитов | нет | текстовый ответ MCP-инструмента | |
| пакетный Конфигуратор | именованное расширение | CheckModules | CheckConfig и применимость | нет | агент вне команды | JSON, лог и DumpResult | |
| LLM + REST-шим к RLM | ошибка по координате стека | нет | нет | диагноз по исходному методу | нет | диагноз в базе | |
| валидаторы EDT + отдельный BSL LS | проект, объекты, запросы | да | да | эвристики, не LLM | штатные исправления | markers и JSON/текст |
BslEdit показывает готовые SARIF 2.1.0-отчёты внешнего анализатора в интерфейсе BSLEdit/BSLView. Файл отчёта читается с диска, а пути диагностик сопоставляются с локальными исходниками конфигурации; для просмотра не нужны запущенная 1С или сетевой сервис.
Нужны Windows и WebView2 Runtime, а также заранее созданный SARIF и доступные исходники. Собственного запуска BSL-анализатора, MCP-инструмента диагностики и автоматических исправлений здесь нет. Сведения отражают последний запуск внешней проверки и не обновляются при изменении BSL. Проверка XML форм и табличных макетов относится к соответствующим категориям и не является анализом кода.
Pi 1C Agent организует ревью через отдельные роли Pi, которые получают явный список файлов или переданный родительским агентом diff. Для синтаксиса и статических диагностик используются отдельно подключённые анализаторы или MCP, а процедуры загрузки и сборки предусматривают пакетные проверки установленным Конфигуратором 1С.
1c-code-reviewer | проверка переданного BSL-кода по требованиям задачи, правилам проекта, стилю и потенциальным дефектам; без предоставленной области проверки запрашивает её вместо догадок. |
|---|---|
1c-arch-reviewer | отдельное архитектурное ревью изменения. |
1c-performance-optimizer | анализ производительности и предложения по оптимизации. |
1c-error-fixer | исправление выявленного дефекта с повторной проверкой. |
mcp-1c-tools | маршрутизация синтаксиса и статических диагностик к доступному BSL Language Server, EDT или серверу проверки; такой сервер устанавливается отдельно. |
/CheckModules, /CheckCanApplyConfigurationExtensions | проверки модулей и применимости загружаемого расширения через CLI Конфигуратора до обновления структуры базы; /CheckConfig применяется для основной конфигурации по условиям процедуры. |
Роли запускаются собственным механизмом дочерних процессов Pi и зависят от выбранной LLM. Ревьюер не исполняет shell и не получает Git diff самостоятельно: область передаёт родитель. Доступность конкретных диагностик определяется внешним анализатором или платформой; пакетные проверки требуют базы и анализируются по коду завершения и журналам. Текстовый результат ревью не является подтверждением успешной компиляции.
Диагностики берутся из служб проверки EDT; дополнительный code review запускает отдельно настроенный BSL Language Server над исходниками проекта.
diagnostics, get_project_errors, get_problem_summary, clean_project, revalidate_objects, get_check_description — маркеры, сводки, перевалидация и объяснение проверок.marker_corrections — список и применение штатных исправлений EDT для checkId; может менять текст модулей, отказывает при несохранённом модуле.validate_query — синтаксическая и семантическая проверка текста запроса в контексте проекта, режим СКД, описание результата и ограниченные исправления текста.validate_for_export, generate_health_snapshot — готовность объектов к выгрузке и сводка состояния.code_review — внешний BSL Language Server JAR, фильтры модулей/важности, таймаут и лимит диагностик.detect_query_anti_patterns, find_rls_violations, sensitive_data_scan, соответствующие операции security_audit — эвристические проверки запросов, RLS и потенциальных секретов.EDT должна быть запущена, проект загружен. Для code review нужен отдельный JAR и совместимая Java. Проверка запроса не исполняет его на данных базы. Эвристические находки требуют оценки разработчиком, а чистые маркеры не доказывают прикладную корректность.
Аудитор кода диагностирует конкретную ошибку по стеку. Расширение передаёт модуль и строку REST-шиму; тот обращается к rlm-tools-bsl, работающему с заданной XML/BSL-выгрузкой, и получает тело метода и вызывающие места. Диагноз формирует модель через коннектор ИИконы.
ДиагностироватьОшибку — публичный BSL-вызов с текстом ошибки, именем модуля и номером строки; возвращает диагноз модели.ДиагностироватьИСохранить — находит ошибку по хешу в регистре мониторинга, извлекает координату и записывает диагноз обратно.Это функции расширения, не MCP tools. Нужны модель, REST-шим, RLM и актуальные исходники; без найденного исходного метода полноценного контекста кода нет. Синтаксические проверки, набор правил статического анализатора, quick fixes и запуск тестов не предоставляются. Ответ LLM требует проверки разработчиком.
Проверяет именованное расширение, загруженное в рабочую базу, через пакетный Конфигуратор. CLI сохраняет JSON-результат, лог, /DumpResult и событие в манифесте.
extension-check --profile quick | /CheckModules для тонкого клиента, сервера и внешнего соединения с расширенной проверкой модулей. |
|---|---|
extension-check --profile full | /CheckConfig с проверкой логической целостности, некорректных ссылок, наличия обработчиков и модулей в тех же контекстах. |
extension-can-apply | /CheckCanApplyConfigurationExtensions для применимости выбранного расширения. |
Нужны Python 3.10+, Конфигуратор и доступ к базе. Успех требует нулевого кода процесса, нулевого результата и отсутствия распознанных диагностик; лог разбирается текстовыми шаблонами. Правки выполняет агент; quick fixes и форматирования нет. Прикладное поведение, динамические вызовы и бизнес-логика требуют отдельных тестов. Навык onec-extension-validate задаёт порядок проверок до обновления и выгрузки артефакта.
Проверка выполняется опциональными модулями Forms и Metadata Authoring по переданным текстовым артефактам. Это проверка узких контрактов генерации, не общий линтер проекта и не запуск Конфигуратора.
check_managed_form | XML, структура формы, ссылки и ограниченные проверки BSL, включая подтверждённые проблемные паттерны. |
|---|---|
check_metadata_artifacts | комплект объекта, UUID, QName, generated types, пути и объявленные формы. |
Статический passed не доказывает нативную загрузку или исполнение. Общей проверки синтаксиса и логики всего BSL-проекта нет; форма проверяется отдельно от комплекта метаданных.
Роль 1c-code-reviewer читает локальные изменения проекта и сверяет их с правилами BSL, требованиями задачи и проектным паспортом. 1c-code-simplifier ищет избыточную сложность. Проверка выполняется агентом в Claude Code; у шаблона нет собственного статического анализатора или MCP tool диагностики. Для текста стандарта и расшифровки кода диагностики инструкции направляют агента к внешнему v8std.
1c-code-reviewer | роль ревьюера по единому чек-листу. |
|---|---|
1c-code-simplifier | роль упрощения кода после реализации. |
1c-rules | локальные правила написания BSL с пометками происхождения. |
/commit | команда анализа diff и оформления логически связанных изменений в Git. |
требования и критерии ревью закреплены в одном наборе правил. Ограничения: синтаксическая диагностика, машинный статический анализ и автоматические исправления зависят от внешних инструментов, если они подключены; набор сам их не выполняет.
Сервер bsl_ls передаёт BSL-код внешнему BSL Language Server: локальному JAR через Java или настроенному HTTP-сервису. Сервер kb проверяет переданный фрагмент по локальной YAML-базе антипаттернов и стандартов. Для этих операций не требуется подключение к базе 1С.
bsl_ls.lint | возвращает диагностики BSL Language Server; принимает список правил и baseline. |
|---|---|
bsl_ls.format | возвращает отформатированный BSL-код без записи исходного файла. |
kb.check_antipatterns | ищет антипаттерны в переданном коде. |
kb.check_standards | проверяет соответствие локальным правилам стандартов. |
kb.get_antipattern | объясняет выбранный антипаттерн и рекомендацию. |
отдельно доступны диагностика, форматирование и проверки по локальной базе знаний. Ограничения: без JAR или HTTP-сервиса BSL Language Server автоматически выбирается заглушка, возвращающая ноль диагностик. Проверки kb.check_antipatterns и kb.check_standards исполняют regex-правила из локального каталога; записи с AST- или BSL LS-детекторами эти два вызова сами не проверяют.
BSL AI Toolkit принимает путь к локальному BSL-файлу или каталогу выгрузки. MCP-сервер bsl-ls запускает установленный JAR BSL Language Server как отдельный процесс и возвращает его диагностики; CLI 1c-meta проверяет обращения к БД внутри циклов по тем же локальным исходникам. Подключение к работающей базе 1С для этих проверок не требуется.
bsl_analyze(src, max_issues, severities, timeout_s) | проверяет каталог или один BSL-файл, возвращает диагностики и явно сообщает, если не был обработан ни один файл. |
|---|---|
bsl_version | показывает версию используемого BSL Language Server. |
1c-meta bsl-gate check | выявляет обращения к БД внутри циклов сверх сохранённого baseline. |
1c-meta bsl-gate baseline | фиксирует исходные находки для последующих проверок. |
проверка конкретных изменённых файлов и явный результат при пустом анализе. Ограничения: нужен Java/JAR BSL Language Server; MCP возвращает диагностики и не применяет исправления. Нативная навигация bsl-ls-native поставляется внешним Language Server, а не этой обёрткой.
BSL Analyzer - локальный анализатор BSL с CLI, LSP и MCP-инсталляцией. В категории проверки кода он закрывает не только синтаксис, но и полноценные диагностические правила проекта.
bsl-analyzer analyze - запускает анализ исходников проекта или каталога; подходит для локальной проверки и CI.bsl-analyzer analyze -r sarif -o <dir> - формирует SARIF-отчет для систем code scanning.bsl-analyzer analyze --format=jsonl - отдает потоковый JSONL-вывод для дальнейшей обработки.bsl-analyzer lsp - поднимает LSP-сервер с diagnostics и code actions для IDE/агента.bsl-analyzer mcp install - устанавливает MCP-конфигурацию; сам анализатор остается основным движком проверки.execute с action check в workspace MCP - выполняет BSL syntax-check через 1С-клиент в сценариях, где нужен runtime/workspace check.есть собственная диагностическая база, конфигурация bsl-analyzer.toml, машинные форматы отчетов, LSP-режим и ориентация на большие проекты. Диагностические типы включают error/code smell/vulnerability/security hotspot и уровни важности.
MCP-часть не выглядит как отдельный универсальный tool check_project; основная ценность проверки находится в CLI/LSP анализатора. Для сценариев "агент вызывает один MCP tool и получает полный отчет" потребуется правильно завернуть CLI/LSP в рабочий процесс.
BSL MCP Analyzer анализирует локальные BSL-файлы смонтированного проекта через Python-движок onec-hbk-bsl. Отдельный контейнер на проект публикует Streamable HTTP MCP через nginx с Bearer-токеном. Индекс SQLite при пустом состоянии заполняется в фоне; повторную индексацию файла агент запускает после правки.
bsl_diagnostics и bsl_check_file — диагностики конкретного BSL-файла;workspace_diagnostics — проверка проекта или каталога с группировкой по правилам, серьёзности и файлам;complexity — цикломатическая и когнитивная сложность каждого метода;module_health — диагностики безопасности, производительности и SQL вместе со сложностью методов, отсортированные по приоритету;bsl_list_rules — список правил анализатора;bsl_fix и bsl_format — предварительный просмотр исправлений и форматирования, применение при явном разрешении записи.проектные сводки и метрики по методам доступны непосредственно как MCP tools. Ограничения: анализируется файловая копия проекта, не живая база; результат зависит от версии закреплённого движка и его правил. У workspace_diagnostics по умолчанию ограничение 2000 BSL-файлов, его можно менять параметром.
1C HBK BSL анализирует локальные BSL/OS-файлы собственным Python-движком с tree-sitter. CLI onec-hbk-bsl check проверяет проект, каталог или файл и выводит text, JSON либо SARIF; расширение VS Code/Cursor и LSP показывают диагностики в редакторе. MCP работает локально через stdio или Streamable HTTP.
bsl_diagnostics, bsl_check_file | диагностики выбранного файла; |
|---|---|
bsl_list_rules | доступные правила; |
bsl_format, bsl_fix | форматирование и автоматические исправления с записью только при write=true; |
bsl_rename | план переименования и транзакционное применение при apply=true. |
CLI дополнительно поддерживает фильтры правил, подавляющие комментарии, baseline и проверку изменений относительно Git. Сильные стороны: единый движок для CLI, LSP, MCP и расширения; машинные отчёты для CI. Ограничения: проверяет файловый проект и не обращается к живой базе. Отдельного MCP tool для агрегированного отчёта всего проекта в базовом наборе нет; такую операцию добавляет надстройка BSL MCP Analyzer.
bsl-context в категории проверки кода - это не линтер и не BSL Language Server. validate_module разбирает целый BSL-модуль или фрагмент, проверяет директивы и обращения к API из shcntx_ru.hbk, а пользовательские методы может разрешать через собственный индекс выгрузки, локальную БД code-index или его MCP-сервис.
validate_enum | проверяет конкретное значение системного перечисления. |
|---|---|
validate_method_call | проверяет число аргументов глобальной функции платформы. |
validate_module | проверяет целый модуль или фрагмент: директивы, конструкторы типов, члены платформенных типов, перечисления, глобальные функции и разрешение пользовательских методов. |
JSON с valid, списком ошибок, строкой/колонкой, видом ошибки, уровнем надежности и подсказкой похожего имени, если она найдена.
хорошо ловит класс ошибок, который обычная модель часто выдумывает: несуществующий тип платформы, несуществующий метод/свойство платформенного типа, неправильное значение системного перечисления, неправильное число аргументов глобальной функции и неизвестный пользовательский метод. Работает локально и зависит от выбранной версии платформы.
не выполняет полную синтаксическую и потоковую диагностику уровня BSL Language Server, не проверяет стандарты, реквизиты, формы и запросы. Индекс пользовательских символов помогает разрешать межмодульные вызовы, но не превращает инструмент в полноценный анализатор всего проекта.
Проверка учитывает символы нескольких конфигураций по alias repo, профили strict/full и разбираемые строковые запросы. Динамически собранные запросы пропускаются; недоступный источник символов делает результат неполным.
Unica подключается к Claude Code или Codex через STDIO MCP и работает с локальными source sets файловой выгрузки. Интерфейс предварительной версии 0.13.0-rc.2 состоит из 11 логических инструментов; стабильный релиз 0.12.3 сохраняет предыдущий контракт. В предварительной версии прежние семейства отдельных tools заменены операциями над адресованными узлами.
unica.check | проверка допуска source set, читаемости и валидаторов выбранного узла, постраничные диагностики. |
|---|---|
unica.apply | проверка плана изменения в dryRun без публикации. |
unica.diff | сравнение узлов до и после изменения. |
Для записи сначала нужен dryRun и его revision в ifRev; допустимые операции объявляются в can выбранного узла. Состав валидаторов и runtime-сценариев зависит от вида артефакта и настроенных драйверов; наличие инструмента не означает поддержку любой операции. Платформа 1С требуется для сценариев сборки и работы с базой.
mcp-1c77 в проверке кода закрывает не общую диагностику BSL, а проверку путей реквизитов для 1С 7.7. Он использует структуру метаданных из 1Cv7.MD и проверяет, существует ли цепочка вроде Товар.Артикул для конкретного объекта.
validate_field_path | проверяет конкретный путь обращения к реквизиту объекта. |
|---|---|
validate_query | находит в тексте запроса или кода обращения вида Документ.Имя.Реквизит и проверяет их по метаданным. |
search_field | помогает найти, где реквизит встречается в объектах метаданных. |
полезен при разборе старого кода 1С 7.7, где ошибка часто связана не с синтаксисом, а с неверным путем к реквизиту или устаревшим именем поля.
это не линтер, не BSL Language Server, не EDT validation и не статический анализатор качества. Он не проверяет синтаксис модуля и не формирует diagnostics/SARIF.
когда нужно проверить обращения к реквизитам в коде или запросе 1С 7.7 по 1Cv7.MD.
1c-lsp-mcp-skill - менеджер нескольких инстансов bsl-language-server и MCP/CLI-bridge к ним. Для проверки кода здесь важен отдельный набор 1c-check.
diagnostics | возвращает синтаксические и статические диагностики BSL Language Server для файла в настроенном проекте. |
|---|
lsp-skill diagnostics <file_path> | CLI-вызов той же проверки, полезный для агентов и локальной диагностики. |
|---|
чистый фокус на BSL Language Server, отдельный LSP-инстанс на каждый 1С-проект, поддержка проектного конфигурационного файла BSL LS и JVM-настроек. Это хороший вариант, когда нужна стабильная диагностика проекта через стандартный BSL LS без Docker.
1c-check намеренно узкий: он про diagnostics. Форматирование, code actions, rename и автоматические исправления в описании skill не заявлены как часть этого проверочного набора.
mcp-bsl-lsp-bridge - bridge между MCP-клиентом и BSL Language Server. Для проверки кода он дает агенту LSP-диагностики и действия исправления.
document_diagnostics | возвращает diagnostics BSL Language Server по конкретному документу. |
|---|---|
project_analysis | запускает проектный анализ через LSP/backend bridge, если проект и backend настроены. |
code_actions | возвращает доступные quick fixes/code actions для диапазона кода или диагностики. |
lsp_status | показывает состояние LSP-сервера; нужен перед диагностикой, чтобы понимать, готов ли индекс/сервер. |
did_change_watched_files | уведомляет LSP об изменениях файлов, чтобы диагностики пересчитывались по актуальному состоянию. |
ближе к IDE-поведению, чем простой запуск анализатора по каталогу: есть диагностики документа, code actions и состояние LSP. Хорошо подходит для агентских сценариев "проверил файл -> получил diagnostics -> применил доступное исправление".
качество правил определяется BSL Language Server. Нужно поддерживать живой LSP/backend и корректно синхронизировать изменения файлов.
BSL MCP Server (Python) - Python MCP-сервер, который запускает BSL Language Server JAR по каталогу или файлу и возвращает результат анализа.
bsl_analyze | анализирует каталог или файл .bsl/.os через BSL Language Server; возвращает статус, количество обработанных файлов, diagnostics по severity и структурированный JSON. |
|---|---|
bsl_format | форматирует BSL-файлы через BSL Language Server; полезен как исправление стиля форматирования, но не заменяет диагностику. |
простой и понятный MCP-wrapper вокруг BSL LS: absolute path на каталог/файл, JSON-результат, сводка ошибок/предупреждений/info. Подходит, когда нужно быстро дать агенту tool "проанализируй каталог".
в описании прямо указано, что платформенную проверку синтаксиса 1С и функций сервер не выполняет. Нужны JRE и JAR-файл BSL Language Server; project-aware возможности ограничены тем, что умеет BSL LS и его конфигурация.
EDT-MCP - MCP-сервер внутри/рядом с 1C:EDT. Для проверки кода он использует модель ошибок и diagnostics EDT workspace.
get_project_errors | возвращает ошибки проекта из EDT workspace. |
|---|---|
get_problem_summary | дает сводку проблем/diagnostics проекта. |
revalidate_objects | принудительно пересчитывает проверки для объектов/ресурсов EDT. |
clean_project | выполняет clean проекта, после которого diagnostics могут быть пересчитаны. |
проверяет проект в контексте EDT, а не только как набор .bsl файлов. Это важно для конфигураций, где ошибки завязаны на структуру EDT-проекта, ресурсы и markers.
требует рабочее окружение EDT. Это не независимый линтер и не BSL LS wrapper; переносимость ниже, зато ближе к реальной EDT-сборке.
Для изображений и структуры визуального макета формы EDT требуется запуск с -DnativeFormBufferedLayoutRender=true. Поддерживаются EDT 2026.1/Java 17 и 2026.2/Java 25; опубликованный набор зависит от toolsets.
Коммерческий плагин работает внутри 1C:EDT с проектом и сервисами среды. По текущей документации предусмотрено 28 tools в профилях Аналитик (12), Разработчик (22), Архитектор (25) и Архитектор Про (28).
get_validation_errors, validate_query, code_review | диагностики EDT, проверка запросов и BSL по стандартам. |
|---|---|
diagnostics | профилирование и диагностика производительности. |
Рекомендуется EDT 2026.1.2/Java 17; EDT 2025 не поддерживается, полная совместимость с 2026.2 не гарантируется. Возможности ограничиваются профилем; для операций базы и тестов нужны соответствующие подключения и компоненты. Исходники плагина не опубликованы, сведения проверены по документации поставщика.
MCP YaXUnit Runner - Java MCP-сервер для запуска тестов и служебных операций 1С. В категории проверки кода важны команды syntax/build validation.
check_syntax_edt | выполняет проверку исходников EDT-проекта через 1C:EDT CLI validate. |
|---|---|
check_syntax_designer_config | выполняет полную проверку конфигурации через CheckConfig в Конфигураторе 1С. |
check_syntax_designer_modules | выполняет CheckModules для точечной проверки модулей конфигурации и расширений. |
build_project | собирает проект; полезен как контроль, что изменения проходят build stage. |
check_platform | проверяет доступность/версию платформенного окружения перед syntax/build-командами. |
закрывает проверки через EDT CLI и Конфигуратор 1С, то есть сценарии, где LSP-диагностик недостаточно. Особенно полезен рядом с тестами YaXUnit, когда нужно объединить syntax check, build и test run.
это runner, а не статический анализатор правил качества. Для глубоких code smell/security diagnostics нужен отдельный анализатор или BSL LS.
v8-runner - локальный Rust CLI и MCP-сервер для рутинных операций разработки 1С. В категории проверки кода он важен как orchestration-tool вокруг build, syntax-check и test pipeline, а не как отдельный анализатор правил.
check_syntax_edt | выполняет проверку EDT-проекта через validate; пустой projectName означает проверку всех настроенных EDT-проектов. |
|---|---|
check_syntax_designer_config | выполняет проверки конфигурации через Designer с флагами designer-config в camelCase. |
check_syntax_designer_modules | выполняет проверки модулей через Designer с флагами designer-modules в camelCase. |
build_project | запускает build проекта перед последующими проверками или тестами. |
run_all_tests | сначала выполняет build, затем запускает все YaXUnit-тесты. |
run_module_tests | сначала выполняет build, затем запускает YaXUnit по конкретному модулю. |
dump_config | выгружает конфигурацию для последующего анализа/сравнения. |
|---|---|
launch_app | запускает нужный клиент/Designer; полезен как служебная операция рядом с проверками. |
один локальный toolchain для build -> syntax -> test, два транспорта MCP (stdio и streamable HTTP), единые timeout/cancellation правила и отдельный shared EDT session path для живого check_syntax_edt. По сравнению с MCP YaXUnit Runner это более широкий локальный runner, а не только MCP-обертка для тестового сценария.
это не LSP и не линтер с собственными правилами качества; он оркестрирует проверки через Designer/EDT и тестовые раннеры. Часть полезных CLI-сценариев (init, extensions, load, make, test va) пока не опубликована как MCP tools.
MCP Host работает внутри запущенной 1C:EDT: операции используют модель открытого проекта, индексы BSL и службы среды. Клиент подключается по HTTP; CLI также обращается к работающему Host.
edt_get_problem_summary, validate_query | диагностики EDT и проверка запросов. |
|---|---|
edt_validate_request | предварительная проверка запроса на изменение метаданных. |
edt_diagnostics | диагностика runtime и рабочей среды через выбранную команду. |
Публикация tools и операции записи зависят от allow/deny-настроек и mutation policy. Ряд изменений метаданных требует токен edt_validate_request. Для runtime и тестов нужны платформа 1С, база и соответствующий тестовый контур. Отдельные dcs/extension/external и QA-операции вызываются через параметр command фасадов.
1C Buddy - открытый прокси/клиент к 1С:Напарнику с MCP, OpenAI-compatible API и веб-чатом. В проверке кода он работает с переданным фрагментом, а не с локальным проектом.
веб-чат может подключать внешние Streamable HTTP MCP-серверы, но это не меняет собственную модель проверки 1C Buddy: локального статического анализа проекта у него нет.
check_1c_code | выполняет синтаксическую проверку или code review фрагмента кода 1С. В direct mode для syntax использует upstream tool mcp__syntax-checker__validate; review-сценарии идут через 1С:Напарник. |
|---|
modify_1c_code | применим после проверки, когда нужно попросить Напарника изменить фрагмент кода по задаче. |
|---|
шире покрывает каналы доступа к Напарнику: MCP, OpenAI-compatible API и web chat. Для категории проверки кода это удобно, когда нужно быстро отдать фрагмент на syntax/review без поднятия локального LSP.
не анализирует весь локальный проект и не строит собственную базу diagnostics. Результат review зависит от 1С:Напарника и формулировки запроса.
MCP доступен по STDIO и Streamable HTTP; отдельная минимальная поставка не включает веб-чат. Требуются Python 3.10+ и токен Напарника; HTTP-зависимости устанавливаются отдельно, полную и минимальную поставки нельзя совмещать в одном окружении.
1C AI MCP - MCP-прокси к 1С:Напарнику. По проверочным сценариям близок к 1C Buddy, но без отдельного веб-чата и OpenAI-compatible слоя в фокусе карточки.
check_1c_code | проверяет фрагмент BSL; поддерживает типы syntax, logic, performance. В direct mode для syntax вызывает upstream tool mcp__syntax-checker__validate, при сбое возвращается к prompt-mode. |
|---|---|
review_1c_code | делает review фрагмента на стиль, стандарты, читаемость и потенциальные проблемы; не заменяет syntax check. |
rewrite_1c_code | переписывает переданный код по задаче. |
|---|---|
modify_1c_code | модифицирует фрагмент кода по инструкции. |
явное разделение check_1c_code и review_1c_code, есть direct mode для syntax-checker Напарника. Хорошо подходит для проверки коротких фрагментов, которые агент уже держит в контексте.
не выполняет локальный анализ проекта и не возвращает SARIF/LSP diagnostics. Для больших кодовых баз нужен отдельный LSP/анализатор.
1C Copilot - Spring MCP-сервер к 1С:Напарнику.
check_1c_code | проверяет переданный BSL-код на ошибки; по описанию поддерживает проверки syntax, logic, performance. |
|---|
минимальный прямой MCP tool для проверки фрагмента через Напарник. Подходит как простой bridge, если нужен только сценарий "передал код -> получил замечания".
меньше специализированных проверочных tools, чем у 1C AI MCP; нет локального проектного анализа, diagnostics по файлам и машинных отчетов.
1c-copilot-mcp проверяет BSL-код через 1С:Напарник. В этой категории важен один tool: check_1c_code.
check_1c_code | комплексно проверяет BSL-код по синтаксису, логике, производительности, архитектуре, стилю, стандартам разработки и лучшим практикам. |
|---|
code | inline-фрагмент BSL. |
|---|---|
file_path, start_line, end_line | чтение кода из файла проекта с выбором диапазона строк; доступ к файлам ограничивается ALLOWED_CODE_PATHS, размер файла ограничен 10 МБ. |
удобен для agent workflow, где код уже лежит в файлах проекта: агент может передать путь и диапазон строк, а не копировать большой модуль в контекст. Проверка просит возвращать проблемы с номерами строк, процедурой/функцией и приоритетом.
это не локальный статический анализатор, не BSL Language Server и не EDT validation. Результат - текстовый ответ 1С:Напарника, без SARIF/LSP diagnostics и без отдельного workflow для применения исправлений.
Claude Code BSL LSP - plugin для Claude Code, который подключает BSL Language Server как LSP-сервер для BSL/OneScript. Это не самостоятельный MCP-сервер, но он относится к проверке кода как канал LSP diagnostics внутри Claude Code.
официальный по владельцу 1c-syntax plugin для Claude Code, с автоматической установкой BSL LS и типичным LSP-набором diagnostics/quick fixes/formatting.
это Claude Code plugin, а не MCP transport. Нельзя напрямую сравнивать с MCP-серверами по tool API.
Claude Code LSPs - набор LSP-плагинов для Claude Code; подкаталог bsl-lsp подключает bsl-language-server.
bsl-lsp plugin - регистрирует BSL Language Server для файлов .bsl и .os.bsl-language-server установлен и доступен в PATH.простой plugin-пакет для пользователей Claude Code, которым нужен BSL LS рядом с другими LSP. Репозиторий активно поддерживает много language-server интеграций.
для BSL это тонкая обертка, а не специализированный MCP-сервер. Установка BSL Language Server в основном лежит на пользователе.
Mini AI 1C - desktop-приложение/agent shell для работы с 1С-кодом. В проверке кода оно использует BSL Language Server и передает diagnostics в LLM-сценарии исправления.
/исправить / действие Исправить - передает выбранные diagnostics и код в LLM для исправления синтаксических ошибок.{diagnostics} - позволяет использовать diagnostics BSL LS в пользовательских командах.удобный пользовательский контур "увидел diagnostics -> выбрал проблемы -> отправил на исправление". Подходит для interactive workflow, а не для серверной проверки проекта.
не MCP-сервер. Для каталога MCP его нужно помечать как связанный desktop-инструмент, а не как полноценный MCP endpoint.
Лицензия разрешает личное некоммерческое использование; коммерческое применение требует согласия автора.
OneRPA MCP servers - платный/закрытый набор серверов OneRPA. В этой категории учитываются SyntaxCheckServer для проверки синтаксиса и 1CCodeChecker для проверок и модификаций BSL через 1С:Напарник.
syntaxcheck | проверяет BSL-код через syntax-check server; по описанию связан с BSL Language Server. |
|---|---|
check_1c_code | проверяет переданный BSL-код. |
review_1c_code | делает review фрагмента кода. |
rewrite_1c_code | переписывает код. |
|---|---|
modify_1c_code | изменяет код по инструкции. |
закрывает syntax-check сценарии и тот же класс задач, что открытые прокси к 1С:Напарнику: проверка/review/исправление фрагмента.
закрытый продукт без исходников в локальном каталоге. Нельзя проверить реализацию, формат diagnostics, поддержанные правила, лимиты, модель запуска и direct mode к mcp__syntax-checker__validate.
Infostart MCP - платный набор, в котором для этой категории учитывается инструмент проверки BSL через BSL Language Server.
mcp-bsl-checker | проверяет BSL-исходники через BSL Language Server; по описанию работает в Docker-контуре с примонтированным каталогом исходников. |
|---|
готовый packaged-вариант BSL LS проверки для пользователей Infostart MCP.
исходников нет. Нельзя подтвердить точный tool schema, формат ответа, настройки BSL LS, поддержку code actions и лимиты контейнера.
AI Code Maestro в категории проверки кода учитывается как закрытый SaaS с плагином для 1C:EDT: сайт заявляет рефакторинг, оптимизацию запросов и помощь с кодом 1С, а FAQ описывает работу внутри 1C:EDT.
удобный продуктовый контур для интерактивной проверки и переписывания кода рядом с задачей.
нет исходников, списка диагностик, формата результата, правил статанализа и контракта для MCP Bridge. Это не подтвержденная замена BSL Analyzer, BSL Language Server или диагностик EDT для CI и машинной проверки проекта.
MCP v8std в категории проверки кода учитывается косвенно: это не проверочный движок, а read-only MCP к базе стандартов v8std.ru и диагностическим страницам. Он полезен после того, как диагностики уже получены из АПК, BSL Language Server, EDT или другого checker.
v8std_explain_diagnostics | объясняет список диагностик АПК, BSL Language Server и EDT, группирует предупреждения и связывает их со стандартами. |
|---|---|
v8std_explain_snippet | подбирает применимые стандарты по короткому фрагменту BSL. |
хороший слой объяснения "почему проверка ругается" и "какой стандарт связан с этой диагностикой"; есть публичный endpoint без ключа и локальный запуск для закрытого кода.
не анализирует файлы, не запускает BSL Language Server, не возвращает LSP diagnostics/SARIF/JSONL и не делает исправления. Для реальной проверки нужен отдельный checker, а MCP v8std подключается как справочный слой после него.
EDT MCP использует установленный каталог проверок EDT: check_catalog перечисляет проверки, check_describe возвращает описание и ссылку на стандарт, check_run запускает валидацию проекта или файла, check_list_markers читает уже созданные markers. write_module дополнительно может проверять синтаксис перед записью.
check_catalog | перечисляет доступные проверки EDT. |
|---|---|
check_describe | описывает выбранную проверку и возвращает ссылку на стандарт. |
check_run | запускает проверку проекта или файла. |
check_list_markers | возвращает созданные EDT markers. |
диагностика выполняется в той же живой EDT-среде, где находится проект. Ограничения: состав правил зависит от установленных EDT-плагинов; отдельного SARIF/CI transport в MCP tools нет.
В категории проверки учитываются только Query/Plan Analyzer capabilities; импорт и аналитика технологического журнала описаны отдельно в категории журналов.
Plan Analyzer — импорт MSSQL .sqlplan/XML, 30 правил PerformanceStudio, SSMS-style visualization, warnings и missing-index recommendations.Query Analyzer — native/semantic SDBL rules, 19 диагностик bsl-language-server, подключаемая XML-конфигурация для проверки объектов/атрибутов и AI rewrite.связывает медленный запрос из ТЖ с планом СУБД, локальными antipattern findings и опциональным AI-объяснением; MSSQL и PostgreSQL разведены по собственным форматам и визуализациям. AI вызывается вручную, а основные rule-based проверки работают локально.
это не анализатор BSL-проекта и не MCP/LSP-интерфейс. В релизном UI Query Analyzer недоступен: nav item включен, но App.tsx возвращает placeholder, а import компонента закомментирован. Поэтому полноценно подтвержденный пользовательский контур v0.1.0 — Plan Analyzer и SQL antipatterns; SDBL analyzer подтвержден backend-кодом и тестами, но не основным UI. AI rewrite/explanation зависит от облака и тарифных лимитов.
когда проблема относится к производительности запроса или execution plan, найденного в ТЖ, а не к общей статической проверке BSL-кодовой базы.
Для проектной статической проверки сильнее всего подходит BSL Analyzer: это отдельный анализатор с CLI/LSP, правилами диагностики, конфигом проекта и машинными отчетами SARIF/JSONL. Его логичнее рассматривать как основу для CI, pre-review и больших проверок кодовой базы.
bsl-context (Regsorm) занимает отдельную нишу: он не заменяет линтер или полноценный BSL Language Server, но разбирает BSL-модуль или фрагмент и сверяет вызовы с API конкретной версии платформы. Его стоит использовать как фильтр против выдуманных платформенных типов, методов, свойств, значений перечислений, неверного числа аргументов глобальных функций и неизвестных пользовательских методов.
Если проверка должна идти через EDT/Конфигуратор 1С, важнее EDT-MCP, MCP:RSV Server, MCP YaXUnit Runner, v8-runner и CodePilot1C MCP Host. Это не замена линтеру: они полезны там, где нужна проверка именно в среде проекта, сборка, EDT markers, validate или CheckConfig/CheckModules.
Unica стоит читать как сценарий Claude Code/Codex для проверки после изменений: unica.check дает диагностический сценарий через внутренний адаптер, а unica.run позволяет связать диагностику с контролем сборки и runtime проекта. Это не отдельный новый анализатор правил, а оркестратор проверочного контура.
MCP:RSV Server относится к той же EDT-группе, но как закрытый коммерческий плагин: он заявляет получение validation errors и проверку запросов. Для CI и независимого статического анализа он не заменяет BSL Analyzer, но полезен в интерактивном EDT-контуре агента.
Инструменты 1C Buddy, 1C AI MCP, 1C Copilot, 1c-copilot-mcp и OneRPA MCP servers проверяют переданный фрагмент через 1С:Напарник. Это полезно для syntax/review/logic/performance-проверок куска кода, но не равно локальному статическому анализу всего проекта. У 1c-copilot-mcp отдельное практическое отличие - чтение проверяемого кода из файла через file_path.
AI Code Maestro относится к классу продуктовых ИИ-проверок: сервис заявляет помощь с рефакторингом, оптимизацией запросов и кодом внутри EDT, но не публикует список диагностик, правила статанализа или машинный формат отчета.
MCP v8std стоит учитывать только как вспомогательный слой вокруг проверки: он не запускает анализатор и не проверяет проект, но помогает агенту объяснить уже полученные diagnostics АПК/BSL Language Server/EDT и сопоставить короткий фрагмент BSL со стандартами v8std.ru.
mcp-1c77 не является статическим анализатором кода. Его место в этой категории узкое: проверка путей обращения к реквизитам в тексте запроса или кода 1С 7.7 по структуре 1Cv7.MD. Для syntax check, BSL LS, EDT diagnostics или правил качества он не подходит.
Claude Code BSL LSP, Claude Code LSPs: bsl-lsp и Mini AI 1C стоит держать в категории как связанные инструменты проверки, но это не самостоятельные MCP-серверы. Они дают diagnostics в конкретной оболочке пользователя.
1C-Optimyzer занимает узкую performance-нишу: он не проверяет BSL-модули целиком, а анализирует запросы 1С и планы исполнения SQL. Plan Analyzer доступен в основном UI, но Query Analyzer в v0.1.0 фактически скрыт placeholder-экраном, несмотря на готовые backend RPC и компонент.
| MCP-сервер структуры конфигураций 1С | Бесплатный / OSS | встроенные статические проверки Forms/Metadata Authoring | переданные XML/BSL-артефакты | ограниченные паттерны | XML, структура, ссылки, типы | нет общего review | генераторы возвращают текст | структурированные diagnostics | исходники |
|---|