MCP for 1C is an MCP server that plugs an AI agent (Claude Code, Codex or Cursor) into the configuration and the database: an AI agent for 1C reads the real code and the real data. The wider the access, the costlier a mistake. Below: what servers exist, what breaks in practice and how to set up access so the agent helps and the production database stays intact. How MCP works in general is covered in MCP for an AI agent.
What an MCP server for 1C is
MCP is a common plug between an agent and a system. For 1C it is an MCP server that gives the agent configuration code and metadata, database data, platform help or checks. Many servers combine several. It works the same way as for any other system: 1C is one more other context, like Jira or GitLab, with the same plug and the same agents. The only 1C-specific part is how the server reaches 1C: through an export, the 1C IDE, a configuration extension or an external data processor.
What an MCP server gives
| Code and metadata | Database data | |
|---|---|---|
| What the agent sees | modules, metadata, forms | catalogs, documents, registers, reports |
| Where from | a configuration export or 1C:EDT | the 1C database through a configuration extension or an external data processor |
| Why | writes code against the real configuration, invents less | answers with numbers from the database, analyses data |
| Main risk | editing the wrong configuration | writes to production, other people's data |
Takeaway
CodeThe agent stops inventing methods and attributes that are not in the configuration.
DataThe agent answers from the database, which means it can also change it. This is where access rules are needed.
What to doStart with code: it is safer. Turn on data access only following the scheme below, even if the server can do both.
How 1C differs for an AI agent
Vibe coding in 1C works differently from regular languages: the program lives in the database and in visual designers, and code is only part of it. The diagram shows the program path from the AI agent's computer to production in GitLab and in 1C.
Program path: local, test, production
LocalIn GitLab the agent edits files and runs tests right away. In 1C it edits the dump and can check it only after loading it into a database, local or test.
VersionsIn GitLab versions live in a git repository with a check. In 1C they live in the configuration repository; git happens but is optional.
Test and productionIn GitLab the program and the data are kept apart. In 1C each environment has its own database holding both: updating production means updating the production database.
Where an AI agent breaks in 1C and why
Pick a number to see what breaks and what helps right under the diagram. Five specifics are the most discussed in 1C developer chats, the sixth is about MCP.
What breaks and where
SpecificModels know the 1C language and its standard library poorly
What breaksinvented methods, SQL syntax instead of the 1C query language
What helpsplatform help through MCP, 2–3 samples from the vendor configuration itself
SpecificService files cannot be edited as text
What breaksthe project drifts from the database, loading hangs for hours
What helpsedits only through the MCP server, direct writes blocked
SpecificForms, reports and print layouts are built with the mouse
What breaksthe agent does not wire events, leaves an empty report, the layout does not change
What helpsthe skeleton by hand, only code to the agent; a form snapshot to check
SpecificA slow check loop
What breaksa database update takes tens of minutes, the agent drops out and reports too early
What helpsupdates in the background, tests on a separate server
SpecificA vendor configuration under support, changes in an extension
What breaksthe agent writes to the main configuration, pulls extra borrowed objects
What helpsthe extension project named in the agent rules, the main one closed
SpecificWriting to production through MCP
What breaksan edit skips storage and test and lands in live data
What helpsproduction read only, writes go to the test database
Takeaway
DifferenceIn 1C the agent needs an intermediary: the IDE, the help and a running platform. Without them it edits what it cannot see.
SizeVendor configurations are huge, with modules of 15–26 thousand lines. The agent gets configuration search and reads only the part it needs.
What to doStart with code and queries; leave forms and reports to a person until the agent shows stable results.
Free MCP servers for 1C and 1C:EDT
There are many ready-made servers and they change fast. Before connecting one, read which actions it supports: read only, or write as well.
mcp-1cConfiguration structure, code search, language help and read-only data queriesCode and dataGitHub
1c_mcpA kit for your own MCP server inside 1C as a configuration extension: configuration out of the box, data through your own toolsCode and dataGitHub
1c-mcp-toolkitConnects to the database through an external data processor, without changing the configurationDataGitHub
MCP:RSV DataAn extension for data and metadata of any configuration: read only, and only what the current user can seeDataInfostart
1C AI Dev ToolsA catalog of servers, skills and integrations for 1C development with AICatalogWebsite
Takeaway
ChoiceCode goes first, data as a second, separate step.
CheckThe server's tool list is the list of what the agent will be able to do to the database.
What to doList the server's tools and mark which of them change data.
What breaks in practice
Open chats of 1C developers describe similar cases. Retold in our own words, without names. These are examples from practice: each case cannot be verified. Pick a case: the diagram shows where it happened, the card shows why and how to protect.
Cases from practice
What happenedBroke the production databaseThe agent got write access to production to move faster. The edit landed in live accounting and was rolled back from a backup.
WhyNo test database between the agent and live data; writes to production were open.
ProtectionProduction read only. The agent writes to a test database; a person moves changes after review.
What happenedDeleted a list of a hundred databasesThe agent was tidying up the server and removed extras, including the list of working databases.
WhyAn account with server admin rights, though the task concerned one database.
ProtectionA separate user for the task, rights to one database only, no server administration.
What happenedGave an accountant the director’s dataAn MCP agent answered employees. An accountant received figures they must not see.
WhyThe server went to the database under one shared user with full rights, so 1C roles and restrictions did not apply.
ProtectionSign in as the person asking: then their roles and record-level restrictions apply.
What happenedPasswords and keys ended up in logsA database password was passed to the agent right in the request. It stayed in the call log and the chat history.
WhySecrets went in tool arguments and lay in files next to the project.
ProtectionSecrets only in server settings, never shown to the agent. Folders with keys closed to the agent.
What happened“Done”, but nothing changedThe agent added an attribute and reported done. In user mode nothing changed: the database was not updated after the edit.
WhyThe agent’s report was accepted without checking the result.
ProtectionAfter an edit: database update, error check and an autotest. “Done” only with a link to the result.
What happenedA query without errors, but a wrong answerThe agent wrote a query that ran without errors, but the figures did not match the 1C report.
WhyThe model knows 1C registers and periods poorly and writes the query as for a regular database.
ProtectionCross-check with the standard 1C report, or answer through a ready report instead of a custom query.
What happenedPersonal data went to the cloudThe agent got a dump with passports and salaries, and it went to a cloud model.
WhyThe agent got the whole database instead of the fields it needed.
ProtectionAnonymization and only the needed fields. For sensitive data, a model inside your perimeter.
Takeaway
Common threadAlmost all cases are about rights and checks. The model is secondary here.
CauseThe agent got as many rights as an administrator, and its report was taken at its word.
What to doGo through the cases and mark which protections you already have.
A safe scheme
The agent only reads the production database. It writes to a test database. A person moves changes to production after review.
Reading apart from writing
StepThe agent readsProduction data and code, for answers and analysis.
WhereProduction, under its own 1C user with a read-only role.
WhyThe agent sees real data but cannot change it.
StepThe agent writesCode, metadata and documents.
WhereA test database or a sandbox with a production copy.
WhyA mistake stays in the test database and never reaches the books.
StepCheck and moveAutotests, then a person reviews the changes.
WhereChanges go to the storage, production is updated from it.
WhyOnly checked changes reach production, and each one has a version.
Takeaway
SchemeThe agent's mistake stays in the test database and never reaches the books.
CostYou need a test database next to production. That is cheaper than one restore from backup.
What to doSet up a test stand with a database copy before connecting the data server.
Rights: an access ladder
The agent's rights are built in steps: each next step opens once the previous one ran without surprises. What agent permissions are
Access ladder
What the agent can doRead codeModules, metadata, forms.
When to openRight away.
How to set upA server with access to the configuration dump or an EDT project, no database access.
What the agent can doRead dataQueries and reports under its own 1C user.
When to openOn a database copy, once code reading caused no surprises.
How to set upA 1C user with a read-only role; the “run any code” tool switched off.
What the agent can doWrite to testCode, metadata, documents.
When to openOnce autotests exist.
How to set upA separate test database; an error check and autotests after every edit.
What the agent can doWrite to productionNothing: this step is closed to the agent.
When to openNever — a person only.
How to set upA person moves changes through the storage after review.
Its own 1C userThe agent signs in as a separate user or as the person who asked. Then the usual rights and record-level restrictions apply.
A read-only roleFor production, a role without the right to write or post documents. Example: in mcp-1c, database queries are read-only by design.
No arbitrary codeTurn off the “run any code” tool on production: it bypasses all rights.
Secrets kept apartPasswords and keys live in server settings. They are never shown to the agent or passed in requests.
Takeaway
Data as commandsA comment in a document or an email in the database can contain an instruction to the agent. That is prompt injection, and rights limit its damage.
RuleThe agent gets the rights of a regular user. What the user cannot do, the agent cannot do either.
What to doHow to tell data from commands is covered in the article on prompt injection.
Checking the result
The agent's “done” is a claim. Checks and a human in the loop confirm it.
Four checks before a result
CheckIDE error check
What it catchesSyntax, methods and attributes that do not exist.
How to runAfter every edit; the agent shows the check result in its report.
CheckAutotests
What it catchesA scenario fails, a form does not open.
How to runScenario and unit tests on the test database every cycle.
CheckCross-check with a 1C report
What it catchesThe agent figures do not match the books.
How to runSame period and company in the standard report; a mismatch means stop.
CheckA person reviews the changes
What it catchesEdits in the wrong place, extra borrowed objects, bypassed tools.
How to runCompare changes before the move: the extension only, the needed objects only.
Takeaway
Common mistakeThe agent edits configuration files around the IDE tools, and the project drifts from the database.
RuleEvery “done” is backed by a check or a link to the result.
What to doAdd to the agent's rules: after an edit, run the error check and show its result.
Claude Code, Codex and Cursor for 1C
An MCP server for 1C connects to any agent that supports MCP. Only the place of setup differs.
Connecting in 3 steps
1. Pick a serverFor code or for data, from the list above
2. Delegate to the agent“Connect the 1C MCP server following its README”
3. Test on a copyAsk for the tool list and look up one catalog
Where to set it up
Where to set upthe
claude mcp add commandFor a team
.mcp.json in the repositoryWhere to set up
~/.codex/config.toml or .codex/config.toml in the projectFor a team
.codex/config.toml in a trusted projectDocsMCP in Codex
Takeaway
Common groundRights are set by the server and the 1C user. The scheme above works with any of the three.
ConfirmationsKeep confirmation on for tools that change data.
What to doDelegate the setup to the agent itself, as described in the MCP article.
Where to start
Three steps. Each next one comes after the previous one went without surprises.
Takeaway
Week 1The code server and reading data on a database copy. Check 5 of the agent's answers by hand.
Week 2Writing to a test database and autotests. The agent shows what it checked.
After thatProduction stays read-only. Moving changes is up to a person.