An MCP Server for 1C: Connecting an Agent to an Accounting System

Demand for tying AI to the 1C platform is growing while ready solutions barely exist. Here is what actually works and which mistakes come first.

What the audience wants

The requests reduce to three:

• Ask the data in words. “How many of these are left”, “what is the status of this order”, “summary for this counterparty this quarter”. Today that is a report, a custom processing routine, or a call to a developer.
• Turn incoming documents into structure. A supplier email, a scanned delivery note, a free-form request becomes a draft document.
• Remove reconciliation drudgery. Match data from an external source against what is in the database.

What all three share: the agent reads and proposes while a person commits. That is not a technology limit but a sensible boundary: an accounting system is where mistakes have consequences.

Options for reaching the data

Four options, worst to best.

Talking to the DBMS directly. Do not. Bypassing the platform means violating its locks, ignoring its permissions and getting data that does not match accounting logic.

OData. The built-in publication mechanism. Easy to enable and exposes configuration objects. The downside: it exposes the platform structure rather than the task, and the agent drowns in attributes.

HTTP services. The best fit. You define which operations exist and return a finished answer to a business question rather than raw objects. That is also your security layer.

A reporting store. Data is exported periodically into a separate store that the agent queries. Maximum safety and no load on the working database; the cost is staleness within the export interval. Best suited to analytics.

Wrapping HTTP services

The shape: the agent calls a tool on the MCP server, the server calls your HTTP service in 1C, that returns data, the server hands it to the agent.

What decides whether it works:

Tools are phrased in task terms, not platform terms. Not “get an item from the Products catalogue” but “find a product by name or SKU and return stock by warehouse”. The agent chooses by description, and it will choose wrongly from a metadata-flavoured one.

The answer arrives finished. Calculations, aggregation and filters belong in 1C, which has a query language for exactly that. Handing the agent a thousand register rows and expecting it to do the arithmetic is a bad idea: it will fill its context and get the sums wrong.

Volume is capped server-side. A mandatory limit on returned rows. Otherwise one badly framed question dumps the whole catalogue into context.

Errors come back as text. “Counterparty not found” is more useful than an empty response: the agent will read it and refine the query rather than inventing data.

How the server and its tools are built: wrapping your own API and a server in Python.

Permissions and security

An order that avoids trouble:

1. A dedicated 1C user with a role limited to reading the required objects. Not an administrator, not “full rights during testing”.
2. Publish on the internal network, not the internet. If external access is unavoidable, HTTPS with authentication only.
3. No write tools at the start. Document modification is added separately, one action at a time, with human confirmation.
4. Call logging on the 1C side: who asked what, and when.
5. Personal data is its own question. Anything that enters context has gone to the model provider. If responses contain personal data, settle that before launch: de-identification, or a local model.

Limits worth knowing in advance

The agent does not replace accounting logic. Postings, period close and scheduled operations are deterministic processes. A probabilistic model has no business in them.

Performance. Every call hits the working database. A dozen questions in a row during the busy part of the day is noticeable. A reporting store solves this better than a cache.

Freshness versus load. A store is fast but lags. Direct access is current but adds load. The choice depends on whether answers must be real time.

Configuration terminology. The standard attribute name and what users call it differ. That gap belongs in the tool descriptions, or the agent will look for the wrong thing.

The protocol overview is in the MCP guide. For an integration built against a specific configuration, see the services page.