1C already contains a company's orders, stock, contracts, calculations and operational history. The difficulty is often reaching a useful answer: opening several reports, checking settings and copying figures into a message. AI can shorten that route by interpreting a request, calling an appropriate tool and explaining the returned result. Both native platform interfaces and public MCP projects can support this. This guide examines material available on 24 October 2026, published examples and a possible local-model architecture.
What work can AI take on?
An accounting assistant starts with a defined operation. “Which products are insufficient for confirmed orders?” requires a period, warehouse, company and agreed reservation rules. AI helps clarify the parameters and interpret the answer. Stock figures should still come from 1C using the approved business logic.
A second task class turns an email, scan or assignment into a prepared document. The model extracts information, matches items and identifies missing facts. Creating an object, saving it and posting it require their own workflow rules. A third class helps developers find configuration objects, prepare queries and test changes. Similar technologies support all three, but their permissions differ.
What MCP connects
MCP standardises communication between an agent application and external tools. A server exposes operations and parameters; a client calls a tool and receives its result. The language model operates inside the application coordinating those calls. The protocol does not itself choose between a local and a hosted model. MCP: official architecture ↗
For 1C, tools might read a document structure, retrieve stock or prepare an order draft. A real connection to the information base is still required, using an extension, HTTP service or another interface. Installing an MCP server neither trains a model on your configuration nor makes every question answerable. Field meaning, data availability and permissions remain integration responsibilities.
A useful tool returns a verifiable business-system result. A useful AI assistant helps a person understand it and choose the next step.
MCP tools you can examine today
GitHub projects offer source code, documentation and different capabilities. The table is a selection guide, not a claim that we installed every project in a production information base. Features were checked against published material; compatibility with a customer's configuration needs separate testing.
| Project | Published capabilities | Appropriate use |
|---|---|---|
| feenlace/mcp-1c | Metadata, data queries, code search | 1C connection and developer support; capabilities depend on edition |
| ROCTUP/1c-mcp-toolkit | MCP and REST, queries, objects, BSL execution | Integration toolkit; arbitrary execution needs separate restrictions |
| yellow-hammer/mcp-1c-platform-tools | Project operations through 1C: Platform Tools | VS Code/Cursor developer environment with the required extension |
| alkoleft/mcp-onec-test-runner (METR) | Builds and YaXUnit execution | Development validation, rather than an accounting chatbot |
| artesk/1C_MCP_metadata | Object structure, metadata search, query validation | Public architecture example; clarify usage conditions |
feenlace/mcp-1c documents metadata access and execute_query limited to SELECT statements. ROCTUP also exposes execute_code for arbitrary BSL, a substantially broader authority. These are not equivalent restricted connections. feenlace/mcp-1c · source snapshot ↗ ROCTUP/1c-mcp-toolkit · source snapshot ↗
1C: Platform Tools MCP connects to a VS Code extension and development operations; METR connects an agent to builds and YaXUnit tests. artesk's project demonstrates configuration metadata and query validation, but public code alone does not determine commercial reuse conditions. Check licences and editions: a product may combine an open foundation with paid capabilities. yellow-hammer/mcp-1c-platform-tools · source snapshot ↗ alkoleft/mcp-onec-test-runner · source snapshot ↗ artesk/1C_MCP_metadata · source snapshot ↗
Alternatives to MCP
1C's standard REST interface uses OData and exposes object operations after publication is configured. It is not inherently read-only: the platform also documents changes and document posting. Deliberate access restrictions matter. 1C:Enterprise · REST interface ↗
For repeated business questions, a custom HTTP service can provide a narrow contract such as stock for selected warehouses, overdue orders or a request draft. The platform supports custom HTTP services. A regular application can call the service directly, or an MCP server can wrap it. These approaches can be combined. 1C: custom HTTP services ↗
When a live connection is unavailable, a pilot can begin with an approved export. This tests question interpretation and response formats, provided the snapshot date stays visible. An external orchestrator can trigger processing on events or schedules. MCP is useful when an agent chooses tools; a fixed sequence may need only ordinary programmatic calls.
What public examples demonstrate
The first is 1C's Primary Document Recognition service. Its official description shows upload, recognition, review and creation of accounting documents. This is an available service and documented operating workflow rather than only a product idea. It does not mean an arbitrary local model reproduces those capabilities, or that the service executes on a customer's local AI station. 1C: Primary Document Recognition ↗
Second, MoscowSoft describes an MCP connection for its marketplace integration module in 1C Trade Management and 1C:UNF. The provider demonstrates assortment analysis, stock coverage and expenses. These are supplier-published examples. Fixing stuck documents is explicitly described as work in development and should not be presented as an existing capability. A public demonstration does not replace independent customer-result verification. MoscowSoft: provider-published marketplace MCP examples ↗
A third example is development with executable feedback: obtaining metadata, modifying code, then building or running YaXUnit through METR. Public repositories establish the availability of components for that workflow. They do not prove an arbitrary model autonomously maintained someone else's production system. Distinguish demonstrations, available components and deployments naming a customer: they represent different levels of evidence. alkoleft/mcp-onec-test-runner · source snapshot ↗
| Example | Published evidence | Interpretation |
|---|---|---|
| 1C document recognition | Official service description and review workflow | Available service; does not establish another model’s local capability |
| MoscowSoft marketplaces | Provider demonstrations and feature description | Data analysis; some document changes remain in development |
| Metadata and METR | Project source code and instructions | Available components; information-base validation still required |
Connecting a local model to 1C
The proposed architecture is straightforward. An employee uses the AI Office application; a local model proposes a tool call; an integration server checks parameters and permissions; 1C returns the requested information. Write operations follow an additional approval route. The information base can remain on the company's existing server. Moving it onto the AI mini PC is not a prerequisite.
Check both directions: which 1C data reaches the model, and which actions the application allows on its behalf. An initial report often needs aggregates, document identifiers and evidence links. Full counterparty records and the entire posting history are unnecessary for every answer.
The application must convert a model's proposal into a valid call matching a defined parameter schema. Evaluate tool use, failure handling and clarification questions alongside the quality of the prose. Protocol compatibility does not establish that the selected local model reliably completes the sequence.
Three scenarios for an initial project
First, a stock assistant. An employee asks how to cover upcoming orders. The application clarifies warehouse and period; 1C calculates available quantities under agreed reservation rules; the model highlights shortages. Include the snapshot time and source-object links. Reconcile “available stock” with the company's usual report before testing: differing settings can produce different figures.
Second, an order from email. A local assistant extracts descriptions, quantities and customer preferences. The 1C catalogue supports product matching, while ambiguous matches remain questions for a manager. Present items, units, counterparty and terms for review. Only then create a draft through an agreed route. If connectivity fails after saving, a retry checks the previous operation rather than creating another order.
Third, an accounts-receivable briefing. An approved query returns documents and amounts for a chosen date. The model groups situations and explains them without inventing reasons for non-payment. Customer messages remain drafts. Initially assess agreement with the reference report and the usefulness of prioritisation, rather than expecting autonomous financial management.
Where local AI is particularly relevant
Internal messages, contracts and management information make customer-controlled model hosting an attractive option. Recognition, text processing and procedure retrieval can be designed to remain local. But if OCR, search or an agent client sends material to an external API, a local text generator alone does not make the whole route local.
Consider a compatible AI station, including a memory-rich mini PC class. Test model size, document length and concurrent requests on the actual setup. A model ranking and 128 GB of installed memory do not establish response times for your 1C workload. Completion time includes database queries, integration work and human review.
Boundaries before enabling writes
Start reading under a separate role restricted to appropriate organisations and objects. A read query can still expose excessive data or overload a database. Repeated tasks benefit from reviewed, parameterised operations with result and time limits rather than unrestricted generated code.
Before a write, show the proposed changes. General permission to “use 1C” is too broad: an employee needs the objects and values involved. Treat posting as a separate action. The integration must respect mandatory fields, permissions, current data and the configuration's business logic.
- Identify operations so their outcomes can be checked after connection failures.
- Record parameters, evidence, results and the approving person.
- Do not accept extra authority from email or attachment content.
- Stop failed workflows with a clear state and a manual continuation path.
Where a company should begin
Prepare configuration and platform versions, a familiar report, several anonymised documents and an example of the expected answer. Test read access and matching on a copy of the information base. Measure explanation quality, clarification frequency and human time to an accepted result. Draft creation and writes can become a subsequent phase.
AI Office can help investigate that workflow with a customer: select an existing adapter or develop a narrow service, connect a local model and evaluate the result. This is an integration tailored to the company's configuration and operating rules. Start with a recurring accounting question that currently takes time to resolve and turn it into a useful working tool.