MCP для 1C: безопасный контур, метаданные и права агента

Раздел

MCP-серверы

Сложность

сложная

Обновлено

2026-05-22

Короткий ответ

MCP для 1C нужен, если AI-агенту требуется управляемый доступ к данным 1C: справочникам, документам, остаткам, заказам, статусам, регламентам или метаданным. Правильный первый шаг - read-only сервер с узкими tools и resources. Неправильный первый шаг - дать агенту возможность менять документы, проводить операции или выполнять произвольные запросы.

1C - система учета, а не песочница для экспериментов. MCP должен стоять как контролируемый слой между агентом и 1C: проверять права, ограничивать методы, писать журнал и возвращать данные в понятном формате.

Эта страница обновлена под запросы mcp сервер для 1с, mcp сервер 1c, 1с edt mcp и cursor mcp 1с. Отдельные тонкие страницы под Cursor или EDT не нужны: практический смысл тот же - дать AI-клиенту безопасный слой чтения и ограниченных tools вокруг 1C.

Краткий brief

Когда MCP нужен

MCP оправдан, если:

• несколько AI-инструментов должны читать одни и те же данные 1C;
• агенту нужно искать справочники, статусы или документы;
• важны права доступа и журнал вызовов;
• нужно отделить чтение от действий записи;
• интеграция должна жить дольше одного прототипа;
• команда хочет подключить 1C к Cursor, Claude Code, Codex или внутреннему агенту.

Если задача разовая и детерминированная, проще сделать обычный REST/OData вызов или отчет. MCP нужен там, где AI-клиентам нужен повторяемый и управляемый способ получать контекст.

Источники данных 1C

Для интеграции обычно смотрят несколько вариантов:

Для MCP-пилота лучше использовать витрину или read-only контур. Прямая работа с рабочей 1C опасна: агент может создать нагрузку, раскрыть лишние данные или получить возможность менять учетные документы.

Cursor и EDT контур

Cursor, 1C:EDT и MCP решают разные части задачи. Cursor или другой AI-host запускает agent workflow. MCP-сервер открывает controlled tools. 1C:EDT помогает разработчику сопровождать расширения, HTTP-сервисы, модули и тестовую базу, но сам по себе не делает доступ безопасным.

Практический контур:

Cursor / agent host
  -> project MCP config
    -> 1C MCP server
      -> read-only replica, OData, HTTP service or test base

Что важно зафиксировать в проекте:

• MCP-конфиг лежит на уровне проекта, а не в личной настройке без review;
• секреты не попадают в репозиторий и prompt;
• tools названы по бизнес-действию: find_counterparty, get_order_status, search_catalog_item;
• каждый tool имеет schema, timeout, rate limit и audit log;
• write-tools выключены до отдельного threat model;
• EDT/конфигурация 1C меняются через обычный review, а не через агентный автоправщик.

Если агент нужен только разработчику для чтения документации проекта, достаточно read-only resources и tools вокруг тестовой базы. Если агент должен помогать пользователям учета, нужен отдельный слой прав: пользователь, роль, разрешенные объекты, журнал и отказ при конфликте доступа.

Какие tools делать первыми

Хорошие первые tools:

• найти контрагента по ИНН;
• получить карточку заказа;
• посмотреть статус документа;
• найти номенклатуру по артикулу;
• получить список открытых задач;
• найти документ по номеру;
• показать метаданные объекта.

Плохие первые tools:

• провести документ;
• изменить цену;
• создать платеж;
• удалить или объединить записи;
• выполнить произвольный запрос;
• менять права и настройки.

На старте агент должен помогать искать и объяснять, а не менять учет.

Метаданные и формат ответа

Агенту нужны не только значения, но и смысл. Если tool возвращает “status: 3”, модель будет угадывать. Возвращайте понятные поля: название статуса, дату, владельца, тип документа, ссылку на источник, ограничения.

Хороший ответ tool:

{
  "document_type": "Заказ клиента",
  "number": "000123",
  "status": "Ожидает оплаты",
  "updated_at": "2026-05-19",
  "source": "1C read-only replica",
  "allowed_actions": ["summarize", "suggest_next_step"]
}

Так агент понимает не только данные, но и границы действия.

Права и журналирование

Права должны проверяться на стороне MCP-сервера и 1C-контура. Нельзя полагаться на prompt. Минимальные правила:

• отдельный технический пользователь;
• read-only доступ для пилота;
• allowlist объектов и методов;
• фильтрация по роли пользователя;
• лимиты на частоту запросов;
• журнал: кто, когда, какой tool вызвал;
• запрет секретов и персональных данных без необходимости;
• отключение сервера при аномалии.

Если агент работает от имени пользователя, сервер должен понимать этого пользователя и его права. Если от технического аккаунта - нужно отдельно ограничить данные, иначе технический аккаунт станет обходом прав.

Конфигурационные границы

Минимальный набор границ для mcp сервер 1c:

Запрещайте общий tool вроде execute_1c_query. Он удобен для демо, но в рабочем контуре стирает все границы: агент может случайно читать закрытые данные, создавать нагрузку и обходить бизнес-логику.

План пилота

1. Выберите один сценарий: статус заказа, контрагент, номенклатура или документы.
2. Поднимите read-only источник: витрина, реплика или ограниченный API.
3. Опишите 3-5 tools.
4. Запретите все действия записи.
5. Добавьте журнал вызовов.
6. Подключите один AI-клиент.
7. Проверьте 30-50 реальных вопросов пользователей.
8. Разберите ошибки и только потом расширяйте tools.

Не начинайте с “агент управляет 1C”. Начните с “агент помогает найти и объяснить данные”.

Для Cursor/EDT сценария добавьте отдельную проверку: конфиг MCP воспроизводится на чистой машине разработчика, секреты не лежат в проекте, tools читают только тестовую или read-only базу, а изменения конфигурации 1C проходят обычный review.

Метрики

Если пользователи получают ответ быстро, но регулярно перепроверяют его в 1C вручную, MCP не дал доверия. Нужно улучшать источники, формат ответа и ссылки.

Чеклист

• Первый контур read-only.
• Нет произвольных запросов.
• Есть allowlist объектов и методов.
• Права проверяются на сервере.
• Используется витрина или ограниченный API.
• Каждый вызов пишется в журнал.
• Ответы содержат понятные статусы и источник.
• Запись добавляется только после отдельного threat model.

FAQ

Можно ли подключить MCP прямо к рабочей 1C?

Для первого пилота не стоит. Лучше read-only витрина, реплика или ограниченный HTTP-сервис.

MCP заменяет OData или HTTP-сервисы?

Нет. MCP может использовать их внутри. Он дает AI-клиенту стандартизированный слой tools/resources.

Можно ли разрешить агенту проводить документы?

Только после пилота, прав, журнала, ручного подтверждения и rollback. Для старта это слишком рискованно.

Как связаны Cursor MCP и 1C:EDT?

Cursor может быть AI-host с MCP-конфигом проекта. 1C:EDT остается средой разработки и сопровождения конфигурации. MCP-сервер между ними должен открывать только разрешенные read-only tools или тестовые операции.

Где хранить MCP-конфиг для 1C?

Проектный конфиг можно хранить в репозитории без секретов, чтобы его ревьюили как код. Токены, строки подключения и пароли должны приходить из env или secret store.

Что читать дальше?

Сначала разберите общий принцип в статье MCP сервер: что это, затем посмотрите Cursor MCP и MCP для CRM и Bitrix24. Для более опасного data-сценария сравните с MCP для Postgres.