v8unpack-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| unpackA | Полная распаковка файла 1С (.cf/.cfe/.epf/.erf) в отдельный временный каталог (без лимита размера, любые объекты). Первый шаг любого цикла. Возвращает путь к каталогу (организованное дерево + raw-слой .v8unpack_raw) |
| unpack_asyncA | АСИНХРОННАЯ распаковка крупного файла 1С. Запускает работу в фоновом задании и СРАЗУ возвращает {job_id, status:'running'} — не ждёт завершения, поэтому не срывается таймаутом клиента. Опрашивайте статус через job_status, пока status!='done'; в result будет тот же результат, что у unpack |
| job_statusA | Статус фонового задания (unpack_async/repack_async): status=running|done|error, progress (число обработанных объектов), result (при status=done — как у unpack/repack), error (при status=error). Опрашивайте повторно, пока status!='done' |
| repackA | Собрать файл 1С из распакованного каталога (результат unpack) в целевой файл |
| repack_asyncA | АСИНХРОННАЯ сборка файла 1С из распакованного каталога. Запускает работу в фоновом задании и СРАЗУ возвращает {job_id, status:'running'}. Результат получите через job_status (status='done', поле result) |
| list_objectsA | Список объектов внутри распакованного контейнера: {вид_объекта: [имена]} (только имена; полные метаданные — get_metadata) |
| get_metadataA | Метаданные распакованного каталога. Без object_path — сводка (вид, счётчики по типам). С object_path='Тип/Имя' — метаданные объекта (имя, синоним, uuid, формы, макеты, модули). detail=true — полный список по типам |
| read_moduleA | Прочитать BSL-модуль объекта из распакованного каталога. object_path — путь к объекту ('' для корня epf/erf, 'CommonModule/Имя' для cf/cfe); module_name — подстрока имени файла модуля (пусто = список модулей объекта); ranges — список диапазонов строк вида 'start-end' (или 'N'), 1-based, суммарно не более 400 строк на пакет (пусто = весь модуль) |
| get_module_structureB | Структура BSL-модуля: объявления переменных (Перем), процедуры и функции (имя, вид, Экспорт, директивы, докстринг, параметры, start/end строки) и секция основной программы (код после процедур). object_path — путь к объекту, module_name — подстрока имени файла модуля |
| read_bytecodeB | Разобрать байт-код закрытого модуля (методы, константы, поток опкодов) из raw-слоя каталога unpack |
| search_codeA | Поиск подстроки/regex по текстовым слоям распакованного каталога. layers: modules, forms, templates_text, templates_html, dcc (пусто = все). scope (для СКД, слой dcc): 'query' (по умолчанию, только тексты запросов) или 'all' (весь XML СКД). Каждое совпадение содержит поле layer |
| set_helpA | Записать справочную информацию (help) объекта в raw-слой каталога unpack (сборку делает repack). object_path пуст для внешней обработки/отчёта, 'Тип/Имя' для конфигурации/расширения. overwrite=false — существующую справку не перезаписывать |
| get_helpA | Прочитать справочную информацию (help) объекта из raw-слоя каталога unpack. object_path пуст для внешней обработки/отчёта, 'Тип/Имя' для конфигурации/расширения. mode='check' — только факт наличия справки; mode='get' — ещё и текст (HTML) + языки |
| import_templateA | Импортировать готовый .mxl (табличный документ) в макет объекта — замена содержимого существующего макета (template_name или единственный). Пишет в raw-слой; сборку делает repack |
| read_templateA | Прочитать табличный документ (MXL) макета в структурированном виде. Декодирует MOXCEL в дерево: возвращает канонический текст structure и список текстовых значений strings. Только чтение |
| read_dcsA | Прочитать схему компоновки данных (СКД) макета. Уровень 1 (без data_set/variant) — обзор: data_sets (имя/тип), parameters, variants (имя/представление). data_set='Имя' — текст запроса и список полей набора. variant='Имя' — сырой XML настроек варианта (как хранится в .bin). Только чтение |
| export_dcsA | Выгрузить СКД макета целиком в XML (штатный формат платформы: ). output_path — куда записать файл; не задан — XML возвращается в поле 'xml'. Только чтение |
| import_dcsB | Загрузить СКД макета целиком из XML (штатный формат платформы). Источник: template_path (файл) или xml_text (строка). Пишет в raw-слой; сборку выполняет repack |
| diffA | Сравнить два распакованных каталога (результат unpack) пообъектно. По содержимому (построчный diff): .mxl (декодируется структурно), .json, .obj.bsl, XML форм. По байтам (только факт изменения, помечается binary=true): зашифрованные .obj.bin, СКД .bin, картинки. full=false — только факт изменения без диффа |
| cleanupA | Удалить временный каталог unpack. dir_path — один каталог; all=true — удалить все каталоги unpack (по префиксу в temp) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Each tool targets a clearly distinct operation: unpack/repack lifecycle with async wrappers and job_status, object enumeration vs metadata, module source vs structure vs bytecode, help/template/DCS read/write variants, search, diff, and cleanup. Even read_dcs and export_dcs are differentiated by granularity (structured exploration vs full platform XML export). No two tools appear to perform the same job.
Most tools follow a verb_noun snake_case pattern (list_objects, get_metadata, read_module, import_template, export_dcs), and async variants consistently use the <verb>_async suffix. Minor deviations include bare verbs like unpack, repack, diff, cleanup, the noun-style job_status, and an arbitrary read/get split among extraction tools. Overall the naming is still predictable and readable.
At 20 tools, the server is on the upper boundary for tool count, but the 1C unpack/repack domain is complex enough to justify dedicated tools for async operations, module analysis, bytecode, help, templates, DCS, diff, and cleanup. A few closely related tools (read_dcs/export_dcs) could potentially be merged, but none feel like filler.
The toolset covers the full lifecycle: unpack (sync/async), inspection (list, metadata, modules, bytecode, search), modification (help, template, DCS imports into raw layer), repack (sync/async), diff, and cleanup. Minor gaps exist—no direct tool for writing arbitrary module code or forms—but editing the unpacked directory externally and repacking is a viable workaround.