MCP-1C: a 1C configuration structure server
MCP 1C
A Docker server with a read-only core and pluggable modules: metadata, code, forms and relations of several 1C configurations through one MCP contract
Medium risk
We rate an entry medium when the tool runs code, makes network calls or reads project files. Check what exactly it does before installing.
Why this level
- Stores and indexes the full source code and structure of 1C configurations in its own data/ store
- Requires an admin token with rights to upload and delete sources, whose compromise exposes the whole knowledge base
Install
Manual install
cp .env.example .env
docker compose up -dAfter filling .env with two different tokens, API_TOKEN and ADMIN_TOKEN.
This is third-party code. Review the repository files before installing.
What it does
The server parses 1C configuration exports (structure, code, forms, relations, virtual tables, platform reference for several versions) and serves them to an agent through MCP, an SPA dashboard and an HTTP API. The always-on read-only core can be extended with capability modules: Forms builds Form.xml and Module.bsl from a canonical spec, validates the result and decompiles it back, without changing the configuration or database, and Metadata Authoring creates and checks an object's metadata bundle, also without writing into the configuration or infobase; all module operations are described as pure. A disabled module doesn't publish its tools and doesn't take up the MCP client's context. The server holds several configurations at once without mixing their data, and runs as a single Docker container with mandatory separate access and admin tokens and a strict non-root setup.
Who it is for. For 1C developers with several large configurations who need a persistently running local context server for an agent, not a one-off local process.
Good fit when
- Several 1C configurations are maintained at once, and the agent must explicitly pick the right one
- You want a human-facing dashboard for sources, relations and server state, not just an API
- You need a form built from a spec with validation, without direct writes into the configuration
Not a fit when
- You can't deploy Docker and prepare a data directory with the correct 10001:10001 owner: the README describes this as a mandatory step
- You need direct writes into the configuration or infobase: both Forms and Metadata Authoring are intentionally pure and only return artifacts as text
- You need a full MXL parser built in: the repository doesn't ship source HBK files or exports, only the runtime over prepared sources
Example request
In the Retail configuration, find all objects related to the stock register and show the relation graphLimitations
The official image requires two different random tokens of at least 32 printable ASCII characters before it even starts, without which the server won't run even on localhost. On Linux, the data directory must be owned by UID:GID 10001:10001 in advance; a plain mkdir -p won't do that. The repository ships no source HBK files, configuration exports or their indexes; those are prepared separately by the administrator and stay outside git. Only one heavy intake operation is supported at a time; a second one gets a 409 before its request body is even read. An unsigned or tampered shared-reference artifact is marked untrusted and the server won't open it.
How to disable. Stop the container with docker compose down and remove the server from your MCP client settings.
MCP
- Transport
- http, stdio
- Authentication
- API key
| Environment variables | |
|---|---|
| API_TOKEN required, secret | Access token for MCP and the dashboard, required, at least 32 characters. |
| ADMIN_TOKEN required, secret | Admin token for uploading, deleting and reloading sources, must differ from API_TOKEN. |
| MCP1C_CAPABILITIES | Bootstraps the enabled module set on first run, until data/server-settings.json exists. |
Security check
- Stores and indexes the full source code and structure of 1C configurations in its own data/ store
- Requires an admin token with rights to upload and delete sources, whose compromise exposes the whole knowledge base
README in short
The README describes in detail a read-only core with pluggable Forms and Metadata Authoring capability modules, a modern dashboard, a modular capability system that needs a fresh MCP session after enabling a module, and a very detailed Docker deployment runbook on a clean Linux host: preparing the data directory with a specific owner, two mandatory tokens, local/http/https-proxy access modes, the difference between Source A and Source B for loading configurations, a two-phase intake API with preview and explicit publication, upload size limits, and a signed read-only shared platform-reference artifact. It covers upgrading from version 3.3.0 to 4.0.0.
FAQ
Does the built form get written straight into the configuration?
No, the Forms module returns Form.xml and Module.bsl as text; the server itself never changes the configuration or infobase.
Can several configurations be handled in one install?
Yes, that's one of the stated reasons the server exists: the agent explicitly picks the configuration it needs and never gets another one's data by accident.
Related
A skills library that gives coding agents a development process: brainstorming, planning, TDD, subagents and code review
Skills for real engineers by Matt Pocock
Skills For Real Engineers
Small composable skills for engineering with agents: plan grilling, TDD, bug diagnosis, code review and architecture
GitHub toolkit for spec-driven development: the specify CLI adds agent commands and skills to a project, from principles to implementation
Reference MCP servers
Model Context Protocol servers
Official reference MCP servers: Filesystem, Fetch, Git, Memory, Sequential Thinking, Time and Everything