1c_mcp: an MCP server built inside a 1C:Enterprise configuration extension

What 1c_mcp actually solves for a 1C shop

A language model answers well only when the context it receives is good, and assembling that context by hand from a 1C:Enterprise database is slow work. The README frames Model Context Protocol as the fix: instead of pasting metadata into a chat window, the model asks your server for what it needs through declared tools. The project supplies the server side of that contract as a 1C configuration extension, so the tools run inside the platform and can reach configuration metadata directly.

The audience is narrow and specific. You need a running 1C:Enterprise base, the right to attach a configuration extension to it, and an AI client that speaks MCP. The README names Claude Desktop and Cursor among the clients, and the repository carries a mcp_client_settings directory with ready-made configurations for several of them. Tools that read 1C configuration metadata are described as available out of the box, which means a first useful session does not require writing any 1C code. Writing your own tools does.

The two components and how a request travels

The repository splits into src/1c_ext, the extension that implements the MCP server and its tools, and src/py_server, a Python proxy that the README calls optional but recommended. The extension also contains an HTTP service named mcp_APIBackend, which you publish on a web server. That publication is the seam everything else depends on.

There are three connection shapes. In the direct one, the AI client talks straight to the 1C HTTP service at a path like .../ваша_база/hs/mcp/. In the proxied one, the client talks to the Python proxy, and the proxy talks to the same HTTP service. The proxy earns its place by fixing two things the direct route cannot. It can expose a stdio transport for clients that require one, and it implements OAuth2 toward the client while passing credentials to 1C as Basic Auth, which means you do not have to strip authentication from the published base. The proxy runs in either of two modes: as one fixed user, or passing each user's own credentials through.

Tool development follows the same split. Inside the engine you create a new data processor, add it to the mcp_КонтейнерыИнструментов subsystem, and implement two exported methods in its manager module. The engine discovers subsystems whose names contain mcp_MCPСервер, so a separate extension can carry its own tools by copying that subsystem and prefixing it, for example МОЙ_mcp_MCPСервер.

Installing the extension and publishing the HTTP service

The README gives a three-step quick start and no installer. Step one is to attach the prebuilt extension from the build directory to your configuration. There is no compilation step described for the reader; the .cfe file is committed to the repository. Note that the file name in the README is MCP_Сервер.cfe, with Cyrillic characters, so copy it exactly rather than retyping it.

Step two is publishing the HTTP service mcp_APIBackend on your web server. The README warns twice about this step. The case of the base name in the URL must match the publication name exactly: base, not Base. A mismatch produces redirects that turn POST requests into GET, which breaks the protocol. The second warning is that connecting an AI client directly to 1C requires publishing the base without authentication by embedding credentials in default.vrd, and the README calls that unsafe.

# From the repository README, Docker route for the proxy
cp .env.docker.example .env
# edit .env: URL, login, password
docker-compose up -d

The third step is pointing your MCP client at the published service. The README's example path is .../ваша_база/hs/mcp/, and the mcp_client_settings folder holds configurations per client. If you take the Docker route for the proxy, the compose file maps ${MCP_PORT:-8000} to port 8000 inside the container and reads variables from .env. The README adds one host-specific caveat: when 1C runs on the same machine, use host.docker.internal instead of localhost in MCP_ONEC_URL. The container health check calls http://localhost:8000/health, so a proxy that starts but cannot reach 1C will still report healthy.

Where 1c_mcp is the wrong choice

The direct connection mode is the weak spot, and the README says so rather than hiding it. Publishing a 1C base without authentication to let an AI client in is a decision many administrators will refuse, correctly. That pushes you to the proxy, and the proxy is a second service to run, configure and keep alive. If your environment cannot host an extra Python process or container, the project's recommended path is closed to you.

The direct mode also cannot serve clients that insist on stdio transport, and the README notes limited compatibility with some HTTP clients because of protocol details it does not enumerate. So the set of clients that work without the proxy is not fully specified.

Two more gaps are worth naming. The README does not document rollback or uninstall of the extension, so plan how you will detach it before you attach it. And the licence line in the README says MIT, while the repository metadata carries no licence identifier; if the licence matters to your legal review, confirm which one governs the files you ship. If your goal is a general-purpose MCP server unrelated to 1C, this project is simply the wrong shape: it is an extension to a platform you must already own.

Compared with writing a standalone MCP server

The obvious alternative is a standalone MCP server in Python or TypeScript that reaches 1C through its own interfaces, typically an HTTP service or an OData endpoint you write yourself. The difference is where the tool logic lives. In 1c_mcp, tools are 1C data processors inside the configuration, registered through the mcp_КонтейнерыИнструментов subsystem and implemented in BSL. The engine handles protocol details, and the tool code runs with the platform's own access to metadata, which is why metadata tools work without any code from you.

A standalone server inverts that. You get ordinary Python packaging, ordinary deployment, and no configuration extension to attach or detach, but you also have to reimplement every metadata query through whatever interface you expose, and you lose the engine's discovery of tool containers. For a team whose 1C developers are the ones who know the data model, keeping tools in BSL is the shorter path. For a team that wants one deployment artifact and no changes inside the 1C base at all, the standalone route avoids the extension entirely. The proxy in this repository is not that alternative; it is a transport and authentication shim in front of the 1C server, and it carries no tool logic.

Maintenance, releases and upgrade cost

The last push to the default branch was on 2026-08-31, and the repository is not archived. Recent releases are close together: v1.5 on 2026-07-12 dealt with OAuth2 fixes and a redirect_uri filter, v1.6 on 2026-07-17 introduced MCP without a web server via file and reverse HTTP transports, and v1.6.1 on 2026-08-03 fixed OAuth2 authorization and role rights. That cadence tells you two things. Authentication and transport are the areas that have been moving, so pin a version and read the release notes before upgrading. And the project's own README states it is under active development, which is a claim about intent, not a guarantee about any particular release.

Upgrade cost has two halves. The Python proxy upgrades like any container or Python package: rebuild, restart, watch the health endpoint. The 1C extension does not. Replacing a .cfe in a production base is a configuration change with its own testing burden, and the README gives no migration notes for the extension between versions, only release titles. Budget for testing each extension upgrade against your own tools, especially after releases that touch OAuth2 or role rights, since those are exactly the areas v1.5 through v1.6.1 changed.

On licensing, the README ends with an MIT License section. That is permissive and generally compatible with commercial use, but the repository metadata does not carry a licence identifier, so treat the README statement as the claim to verify rather than a settled fact. This is not legal advice; if your organisation requires a confirmed licence, check the file that actually ships with the code.

Editorial conclusion

Adopt 1c_mcp if you already run 1C:Enterprise and want an AI assistant to read configuration metadata through the MCP tool contract, and you are willing to run the Python proxy rather than expose the HTTP service directly. Skip it if you have no 1C base, if you need a server that works without publishing an HTTP service, or if you cannot accept that the README does not document rollback or uninstall of the extension. Before committing, verify the case of your publication name matches the URL path exactly, confirm that src/py_server/README.md covers the proxy mode you need (single fixed user or per-user pass-through), and check the build/MCP_Сервер.cfe file against your platform version.

Frequently asked questions

Official sources

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