1c_mcp: an MCP server for 1C:Enterprise, built as a configuration extension

The gap this fills between a 1C database and an LLM client

An LLM answering a question about a 1C configuration needs context: metadata structure, object names, attribute types, maybe live records. The README states the premise plainly, that answer quality depends on the quality of the context handed to the model, and that assembling that context by hand is laborious. The Model Context Protocol inverts the flow. Instead of a developer pasting schema dumps into a chat window, the model requests data through named tools that a server exposes. The project's job is to be that server, inside 1C. The audience is narrow and specific: 1C developers and integrators who want Claude Desktop, Cursor or another MCP-capable client to reach a live 1C:Enterprise base, and who are willing to write the tool logic in BSL rather than in Python or TypeScript. Tools for working with configuration metadata are described as available out of the box, so a first useful session does not require writing any code.

Two components: the BSL engine and the Python proxy

The repository splits into src/1c_ext/ and src/py_server/. The first is the core: a 1C configuration extension that implements the MCP server and hosts tools. The second is described as optional but recommended, and exists to absorb infrastructure problems that 1C cannot solve on its own. The README names those problems directly. Transport: some MCP clients speak only stdio, and an HTTP service cannot serve them, so the proxy bridges stdio to HTTP. Authentication: MCP expects OAuth2, while 1C exposes Basic Auth, so the proxy terminates OAuth2 and forwards credentials to 1C. That second point matters because the alternative, a direct connection, requires publishing the base with authentication disabled, which the README calls unsafe. The proxy runs in two modes: a single fixed user, or pass-through where each user's own credentials reach 1C. A Docker path exists for the proxy, with a .env.docker.example file to copy and docker-compose up -d to start it; the README warns that if 1C runs on the same host, MCP_ONEC_URL should use host.docker.internal rather than localhost.

Getting it running: cfe, publication, client settings

Installation is three steps in the README. First, connect the prebuilt extension from build/MCP_Сервер.cfe to your configuration. Second, publish the HTTP service named mcp_APIBackend that the extension contains. Third, point an MCP client at the published path, which follows the shape .../ваша_база/hs/mcp/, with ready-made client configurations in mcp_client_settings/. One warning is worth repeating verbatim in spirit: the case of the base name in the URL must match the publication name exactly, because a mismatch causes redirects that turn POST requests into GET, which breaks the protocol exchange. The README also flags that a direct client-to-1C connection without the proxy requires publishing without authentication, embedding credentials in default.vrd, and it labels that unsafe. The Docker route is the only place with literal commands: copy .env.docker.example to .env, edit the URL, login and password, then run docker-compose up -d. Everything else about proxy configuration lives in src/py_server/README.md, which is not part of the supplied material, so exact environment variable names beyond MCP_ONEC_URL cannot be confirmed here.

Writing a tool: two export methods and a subsystem name

Tools are added by creating a new 1C data processor, registering it in the subsystem mcp_КонтейнерыИнструментов, and implementing two export methods in the manager module. ДобавитьИнструменты(Инструменты) declares which tools the processor offers and their parameters. ВыполнитьИнструмент(ИмяИнструмента, Аргументы) runs the logic when the model calls one. That is the whole contract, and it keeps MCP framing out of business code. The second option is more interesting: you can ship your own separate extension instead of editing the core one, but you must copy the subsystem mcp_MCPСервер into it and prefix the name with your own extension prefix, for example МОЙ_mcp_MCPСервер. The engine discovers subsystems whose names contain mcp_MCPСервер and connects them the same way it connects its own. This is a string-matching discovery rule rather than a registry, and it has a predictable consequence: rename or mistype the copied subsystem and your tools silently fail to load, with no registration step to catch the error. Beyond tools, the README states the project also supports Resources for static context such as files, and Prompts for prepared message templates.

Where the design forces a trade-off

The three connection modes are not equivalent, and the README is honest about it. Direct connection is simplest and least safe: no authentication on the published service. Proxy connection is recommended and safer, but adds a moving part, a Python process or container, that must be running for the assistant to work at all. Docker isolates that process but introduces its own networking quirk, the host.docker.internal substitution. The direct path also cannot serve clients that require stdio, and the README notes limited compatibility with some HTTP clients due to protocol nuances, without enumerating which ones. So the practical rule is: if your client speaks HTTP and you accept the authentication exposure, direct works; otherwise you are running the proxy, and you have taken on a service to operate. A second limitation is structural. Every tool is BSL code inside a 1C extension, which means the people who can extend this server are 1C developers, not the Python or TypeScript developers who usually wire up MCP servers. For a team without BSL capacity, the out-of-the-box metadata tools are the ceiling.

How this differs from a generic MCP server framework

The obvious alternative is a general MCP server written in Python or TypeScript that talks to 1C through an external interface, COM, or a REST service you write yourself. The difference in approach is where the protocol lives. In 1c_mcp, the MCP server is a 1C extension, so tool code runs inside the platform with direct access to metadata, query language and business logic, and no serialization layer stands between the tool and the database. In the generic-server approach, the MCP server is a separate process that reaches 1C over some published interface, which means every tool needs a corresponding endpoint or query path on the 1C side, plus mapping code in the server language. That is more work per tool and more surface to maintain, but it is written in a language far more developers know, and the MCP process can be deployed independently of the 1C platform. The proxy in this project is a partial concession to that world: it handles transport and OAuth2 in Python, but the tools themselves stay in BSL. Choose 1c_mcp when the tool logic is genuinely 1C logic. Choose a generic server when the tool logic is mostly data retrieval that another language can express.

Maintenance, releases and licence

The release history shows a project that is still settling its authentication story. v1.5 addressed OAuth2 fixes and a redirect_uri filter, v1.6 introduced MCP without a web server via file and reverse HTTP transports, and v1.6.1 fixed OAuth2 authorization and role rights. Three releases in roughly two months, with two of them touching auth, tells you the security-adjacent surface is the active work. The README states the project is actively developed and invites issues. For upgrade cost, the extension is a .cfe you reconnect, and the proxy is a Python package or container you redeploy, so the mechanical cost is low; the real cost is re-verifying authentication behaviour after each release that touches it, and re-checking that your own prefixed subsystem is still discovered. On licensing, the README ends with MIT License. The repository metadata supplied here lists the licence as unknown, and no LICENSE file content was provided, so treat the MIT statement as the project's claim and confirm the actual file before you redistribute the extension inside a commercial configuration. Nothing here is legal advice.

Editorial conclusion

Adopt it if you already run a published 1C HTTP service and have BSL developers who can write ДобавитьИнструменты and ВыполнитьИнструмент handlers, and if your AI client can reach an HTTP endpoint or you are willing to run the Python proxy. Do not adopt it if you need a client that only speaks stdio and you cannot deploy the proxy, or if you cannot publish the mcp_APIBackend service at all. Before committing, verify three things: that the case of your base name in the URL matches the publication name exactly, that you have a plan for authentication that does not involve publishing the base without it, and that the MIT licence and the extension's behaviour on your platform version are acceptable, since the repository states MIT but the licence file itself is not part of the supplied material.

Official sources

1. Issues
2. README
3. Releases
4. vladimir-kharin/1c_mcp on GitHub