v8unpack-mcp
This is an MCP server (stdio) for the full lifecycle of working with 1C binary containers (.cf/.cfe/.epf/.erf): unpack, read/edit, repack, and cleanup, including decompilation of closed modules.
Unpack files synchronously or asynchronously into an organized tree plus a raw layer in a temp directory.
List objects and get metadata (types, object details, forms, templates, modules).
Read BSL module source or get module structure; read bytecode of protected modules.
Find and decompile closed modules, with detection of obfuscated ones.
Search code/text/regex across layers: modules, forms, text/HTML templates, and DCS query texts.
Read and write object help (set_help/get_help) in the raw layer.
Read, import, and export MXL spreadsheet templates and data composition schemas (DCS).
Repack a directory back into a 1C file (synchronously or asynchronously), automatically using raw, granular, or full organized assembly.
Diff two unpacked directories, including structural MXL diffs and binary-change detection.
Cleanup temporary unpack directories, individually or all.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@v8unpack-mcp unpack D:/files/report.epf and list its objects"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
v8unpack-mcp
MCP server (stdio) for the full lifecycle of working with 1C binary files
(.cf / .cfe / .epf / .erf) without importing into an EDT project:
unpack → чтение/правка → repack → cleanupThe single unpacking point is unpack. All other tools accept
dir_path — a directory created by unpack — and do not perform implicit unpacking.
Features
Tool | Signature | What it does |
|
| full unpacking into a separate temporary directory (no size limit), returns the path |
|
| list of objects inside the container |
|
| metadata: type, counters by type, object (uuid, synonym, forms, layouts, modules) |
|
| BSL module source of the object (protected ones are marked |
|
| bytecode analysis of a closed module (methods, constants, opcodes) |
|
| substring/regex search across code, forms, layouts ( |
|
| write object help into the raw layer (assembly is done by |
|
| compare two unpacked directories object-by-object + diff |
|
| assemble a file from the unpacked directory |
|
| delete the unpack directory (or all by prefix) |
Searching for .cf/.cfe/.epf/.erf binaries on disk is done with standard client
file tools (glob/list).
Workflow
unpack(file_path)→{status, dir, file, kind}. Thedirdirectory contains:organized tree (
Type/Name+.json/.obj.bsl/ forms / layouts) — reading and editing code, forms, layouts, attributes;raw layer
.v8unpack_raw/(brace files:text/image/help) — forread_bytecode/set_help.
Reading —
list_objects/get_metadata/read_module/read_bytecode/search_code; editing — via files indir(orset_help).repack(dir_path, output_path)→{status, output, bytes}.cleanup(dir_path)(orcleanup(all=true)).
Errors (missing file/directory, wrong type) are raised as exceptions. The directory after
repack is not deleted automatically — it can be reused for multiple assemblies.
repack scheme
repack assembles via v8unpack.build(use_raw=True):
organized tree not modified → the raw layer is restored byte-for-byte (help, bytecode, encrypted modules are preserved);
organized tree modified → reassembly from the organized tree.
Limitation (all-or-nothing): in one session, either organized-layer edits (code/forms) or raw-layer edits (help/bytecode) — not both. Per-object merging is a separate task.
What search_code looks for
.bsl— module sources;.json— object headers, attributes, and form element trees;.txt/.html— text and HTML layouts;.bin(SKD) — data composition schema: binary prefix + XML with query text.
The layers parameter restricts search areas: modules (.bsl), forms (.json),
templates_text (.txt), templates_html (.html), dcc (.bin-SKD). Empty = all.
Each match contains a layer field.
Not searched (binary): .mxl (tabular document), images, roles (.c1brace),
encrypted modules. The MXL parser is a separate research task (see .ai/).
Comparison (diff)
diff(dir_a, dir_b, full=true) compares two unpacked directories object-by-object:
enumerates object directories (
Type/Namefor cf/cfe, root for epf/erf);collects each object's files (excluding the service
.id.json);statuses:
changed/added/removed/unchanged;for changed objects, a
unified diffis built, truncated by limits (MAX_DIFF_LINES=400, MAX_DIFF_FILES=20);full=false— only the change fact, without building the diff.
Related MCP server: 1C MCP Server
Architecture
Unpacking core — saby v8unpack (Python, MIT). Vendored into
src/v8unpack/with local patches (keep_raw/use_raw,detect_formatfor 8.3.24+, tolerance to unknown metadata groups).Own wrapper —
src/v8unpack_mcp:core.py(logic),textlayers.py(text layer extraction),server.py(MCP server).Unpacking goes into a separate temporary directory
%TEMP%\v8unpack_unpack_*for eachunpackcall; no shared cache (the agent manages the lifecycle itself viacleanup).For MCP, we disable v8unpack multiprocessing (serial pool) and silence stdout/stderr so as not to break the stdio protocol;
OrganizerFile.pack/unpackskip.v8unpack_raw.
v8unpack-mcp/
├── src/
│ ├── v8unpack/ # вендоренное ядро saby v8unpack (MIT) + патчи
│ └── v8unpack_mcp/
│ ├── __init__.py
│ ├── __main__.py # python -m v8unpack_mcp
│ ├── core.py # инструменты: unpack/чтение/правка/repack/cleanup
│ ├── textlayers.py # извлечение текстовых слоёв (поиск)
│ ├── bytecode.py # чтение байт-кода закрытых модулей (из raw-слоя)
│ ├── decompiler.py # декомпилятор байт-кода → BSL
│ ├── diffing.py # сравнение распакованных каталогов
│ └── server.py # MCP-сервер (stdio)
├── tests/
│ ├── test_core.py
│ └── test_server_e2e.py
└── pyproject.tomlInstallation and launch
# MCP-сервер (вендоренное ядро v8unpack входит в пакет)
pip install -e .
# запуск (stdio)
python -m v8unpack_mcp
# или консольная команда
v8unpack-mcpConnecting to a client (MCP)
The server works over stdio: each client launches it as a separate process
with a single command. All tools accept absolute paths to files, so the
process working directory does not matter. Temporary unpacking directories are created in
the system %TEMP% with the v8unpack_unpack_ prefix.
The recommended launch command is the console script v8unpack-mcp (created during
pip install) or python -m v8unpack_mcp. For GUI clients that do not inherit
your PATH, it is safer to specify the absolute path to the interpreter.
Standard MCP format (command + args)
Claude Desktop, Claude Code, Cline, Continue, Roo, VS Code (.mcp.json) and others
use a common format with command and args fields:
{
"mcpServers": {
"v8unpack": {
"command": "v8unpack-mcp",
"args": []
}
}
}Or with an explicit interpreter:
{
"mcpServers": {
"v8unpack": {
"command": "~/путь/к/python.exe",
"args": ["-m", "v8unpack_mcp"]
}
}
}Where to place it:
Claude Desktop —
claude_desktop_config.json(Settings → Developer → Edit Config);Claude Code —
~/.claude.jsonor project.mcp.json;Cline / Continue / Roo — project
.mcp.json(shared between team members) or user settings;VS Code —
.vscode/mcp.json(for the project server) or user settings.
Kilo Code / Kilo CLI (kilo.json, command is an array)
The Kilo format differs: servers are specified in kilo.json under the "mcp" key, and the command
is passed as a single array (without splitting into command+args). The file is the project-level
./kilo.json / .kilo/kilo.json or the global ~/.config/kilo/kilo.json.
// kilo.json (проект)
{
"mcp": {
"v8unpack": {
"type": "local",
"command": ["v8unpack-mcp"],
"enabled": true,
"timeout": 15000
}
}
}Or via python -m:
{
"mcp": {
"v8unpack": {
"type": "local",
"command": ["python", "-m", "v8unpack_mcp"],
"enabled": true
}
}
}The server is enabled/disabled in the TUI with the /mcps command. An inherited server can be
disabled: { "v8unpack": { "enabled": false } }.
Server tool permissions are set by v8unpack_* keys (glob, the last match
from top to bottom takes effect):
{
"permission": {
"v8unpack_*": "allow"
}
}Recommendations for multiple clients
Installation: once
pip install -e .(for development) orpip install dist/v8unpack_mcp-0.2.0-py3-none-any.whl(from a built wheel); thev8unpackdependency is pulled automatically frompyproject.toml.Single interpreter: use the console command
v8unpack-mcp(it lands in the installationPATH) or the same absolute path topython.exein all configs — then any client will pick up the same installation.Clients are independent: each client holds its own stdio process; the only shared state is the temporary unpack directories on disk. You can safely connect the same server to multiple clients simultaneously.
Paths with spaces/Cyrillic: quote paths in JSON configs; in the
commandarray (Kilo), elements are escaped automatically.Quiet launch: the server silences unpacking progress and works only over stdio — no interactive output needs to be added to configs.
Build
pip install build wheel # инструменты сборки
python -m build # создаст dist/v8unpack_mcp-<ver>-py3-none-any.whl и .tar.gz
pip install dist/v8unpack_mcp-0.2.0-py3-none-any.whl # установка из колесаTests
python tests/test_core.py # юнит-смоук ядра
python tests/test_server_e2e.py # end-to-end через stdioTests use files from ../testdata (personal files, not included in git — place your own).
Limitations
Large
.cffiles (hundreds of MB — GB):unpackperforms a full extract into a separate directory. A per-object index (reading one object without a full extract) is the next step.Tabular layouts (
.mxl) are not searched yet — binary format, parser is in the TODO.Protected (encrypted) modules: the source cannot be recovered without the password, but
read_bytecodeparses the compiled bytecode, anddecompiler.pycan decompile it into BSL (thedecompiletool is planned).Edits to the organized layer and the raw layer (help/bytecode) are not merged in one session (all-or-nothing
use_raw).
Borrowed components
The project reuses open community developments:
Component | License | Purpose | Link |
saby v8unpack | MIT (Copyright 2015 infactum) | 1C container unpacking/assembly core — vendored into | |
EvilBeaver/v8asm | MIT | 1C bytecode stack format and opcode table | |
1C-inversion | no explicit license (educational, v8asm fork) | bytecode → BSL decompilation algorithm |
saby v8unpack is included in the package as src/v8unpack/ (the MIT license is preserved in
src/v8unpack/LICENSE). decompiler.py is a port of the 1C-inversion algorithm; bytecode.py
uses the v8asm format.
⚠️ Legal notice. See DISCLAIMER.md and LICENSE:
The project is distributed under the MIT license "as is", without warranties — use at your own risk.
The "1C:Enterprise 8" license prohibits modifying the product's code/data with non-standard means, as well as decompiling the software part of the system. This restriction protects the platform and standard 1C configurations; it does not apply to your own configurations, extensions, and external reports/processing — work only with your own objects.
Decompilation of closed (password-protected) modules is implemented for research purposes and must not be used to crack or remove protection from others' configurations (Article 146 of the Russian Criminal Code). Use it only to recover your own modules.
Useful links
saby v8unpack: https://github.com/saby-integration/v8unpack
EvilBeaver/v8asm: https://github.com/EvilBeaver/v8asm
1C-inversion: https://github.com/ProhorP/1C-inversion
MXL8 format (spec): https://github.com/azubar/SpreadSheet/blob/main/docs/format-mxl.md
Available Tools
20 toolscleanupA
Удалить временный каталог unpack. dir_path — один каталог; all=true — удалить все каталоги unpack (по префиксу в temp)
Inputs: all, dir_path. Returns: result
diffA
Сравнить два распакованных каталога (результат unpack) пообъектно. По содержимому (построчный diff): .mxl (декодируется структурно), .json, .obj.bsl, XML форм. По байтам (только факт изменения, помечается binary=true): зашифрованные .obj.bin, СКД .bin, картинки. full=false — только факт изменения без диффа
Inputs: dir_a (required), dir_b (required), full. Returns: result
export_dcsA
Выгрузить СКД макета целиком в XML (штатный формат платформы: ). output_path — куда записать файл; не задан — XML возвращается в поле 'xml'. Только чтение
Inputs: dir_path (required), object_path, output_path, template_name. Returns: result
get_helpA
Прочитать справочную информацию (help) объекта из raw-слоя каталога unpack. object_path пуст для внешней обработки/отчёта, 'Тип/Имя' для конфигурации/расширения. mode='check' — только факт наличия справки; mode='get' — ещё и текст (HTML) + языки
Inputs: dir_path (required), mode, object_path. Returns: result
get_metadataA
Метаданные распакованного каталога. Без object_path — сводка (вид, счётчики по типам). С object_path='Тип/Имя' — метаданные объекта (имя, синоним, uuid, формы, макеты, модули). detail=true — полный список по типам
Inputs: dir_path (required), detail, object_path. Returns: result
get_module_structureB
Структура BSL-модуля: объявления переменных (Перем), процедуры и функции (имя, вид, Экспорт, директивы, докстринг, параметры, start/end строки) и секция основной программы (код после процедур). object_path — путь к объекту, module_name — подстрока имени файла модуля
Inputs: dir_path (required), module_name, object_path. Returns: result
import_dcsB
Загрузить СКД макета целиком из XML (штатный формат платформы). Источник: template_path (файл) или xml_text (строка). Пишет в raw-слой; сборку выполняет repack
Inputs: dir_path (required), xml_text, object_path, template_name, +1 more. Returns: result
import_templateA
Импортировать готовый .mxl (табличный документ) в макет объекта — замена содержимого существующего макета (template_name или единственный). Пишет в raw-слой; сборку делает repack
Inputs: dir_path (required), object_path, template_name, template_path. Returns: result
job_statusA
Статус фонового задания (unpack_async/repack_async): status=running|done|error, progress (число обработанных объектов), result (при status=done — как у unpack/repack), error (при status=error). Опрашивайте повторно, пока status!='done'
Inputs: job_id (required). Returns: result
list_objectsA
Список объектов внутри распакованного контейнера: {вид_объекта: [имена]} (только имена; полные метаданные — get_metadata)
Inputs: dir_path (required). Returns: result
read_bytecodeB
Разобрать байт-код закрытого модуля (методы, константы, поток опкодов) из raw-слоя каталога unpack
Inputs: dir_path (required), object_path. Returns: result
read_dcsA
Прочитать схему компоновки данных (СКД) макета. Уровень 1 (без data_set/variant) — обзор: data_sets (имя/тип), parameters, variants (имя/представление). data_set='Имя' — текст запроса и список полей набора. variant='Имя' — сырой XML настроек варианта (как хранится в .bin). Только чтение
Inputs: dir_path (required), variant, data_set, object_path, +1 more. Returns: result
read_moduleA
Прочитать BSL-модуль объекта из распакованного каталога. object_path — путь к объекту ('' для корня epf/erf, 'CommonModule/Имя' для cf/cfe); module_name — подстрока имени файла модуля (пусто = список модулей объекта); ranges — список диапазонов строк вида 'start-end' (или 'N'), 1-based, суммарно не более 400 строк на пакет (пусто = весь модуль)
Inputs: dir_path (required), ranges, module_name, object_path. Returns: result
read_templateA
Прочитать табличный документ (MXL) макета в структурированном виде. Декодирует MOXCEL в дерево: возвращает канонический текст structure и список текстовых значений strings. Только чтение
Inputs: dir_path (required), object_path, template_name. Returns: result
repackA
Собрать файл 1С из распакованного каталога (результат unpack) в целевой файл
Inputs: dir_path (required), output_path (required). Returns: result
repack_asyncA
АСИНХРОННАЯ сборка файла 1С из распакованного каталога. Запускает работу в фоновом задании и СРАЗУ возвращает {job_id, status:'running'}. Результат получите через job_status (status='done', поле result)
Inputs: dir_path (required), output_path (required). Returns: result
search_codeA
Поиск подстроки/regex по текстовым слоям распакованного каталога. layers: modules, forms, templates_text, templates_html, dcc (пусто = все). scope (для СКД, слой dcc): 'query' (по умолчанию, только тексты запросов) или 'all' (весь XML СКД). Каждое совпадение содержит поле layer
Inputs: pattern (required), dir_path (required), regex, scope, +3 more. Returns: result
set_helpA
Записать справочную информацию (help) объекта в raw-слой каталога unpack (сборку делает repack). object_path пуст для внешней обработки/отчёта, 'Тип/Имя' для конфигурации/расширения. overwrite=false — существующую справку не перезаписывать
Inputs: dir_path (required), help_html, overwrite, object_path. Returns: result
unpackA
Полная распаковка файла 1С (.cf/.cfe/.epf/.erf) в отдельный временный каталог (без лимита размера, любые объекты). Первый шаг любого цикла. Возвращает путь к каталогу (организованное дерево + raw-слой .v8unpack_raw)
Inputs: file_path (required). Returns: result
unpack_asyncA
АСИНХРОННАЯ распаковка крупного файла 1С. Запускает работу в фоновом задании и СРАЗУ возвращает {job_id, status:'running'} — не ждёт завершения, поэтому не срывается таймаутом клиента. Опрашивайте статус через job_status, пока status!='done'; в result будет тот же результат, что у unpack
Inputs: file_path (required). Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
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.
Maintenance
Related MCP Connectors
Document conversion MCP server: PDF to Markdown, image OCR, spreadsheet parsing.
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceMCP server providing tools for interacting with 1С:Напарник AI, including asking questions, syntax explanation, code review, and documentation search. Also serves as a web chat interface and OpenAI-compatible API gateway.109AGPL 3.0
- FlicenseNot gradedqualityDmaintenanceActs as a bridge between AI agents (Claude, Cursor) and 1C:Enterprise databases, enabling metadata retrieval, configuration analysis, and code generation through natural language using the MCP protocol.-
- FlicenseNot gradedqualityBmaintenanceMCP server for searching and analyzing 1C enterprise metadata and BSL code using a SQLite backend. Enables querying configuration structure, code routines, and performing compliance checks via natural language.-
- AlicenseBqualityCmaintenanceLightweight MCP server for 1C.ai integration, enabling queries, code analysis, and documentation search via natural language.82AGPL 3.0