Архитектура шлюза

MCP шлюз (Корпоративная редакция MCP-1C) это self-hosted MCP-сервер для командной работы с 1С. Организация разворачивает один экземпляр в своём контуре, и вся команда подключается к нему из IDE и чат-клиентов (Cursor, Claude Desktop и других). У каждого пользователя своя аутентификация, доступ разграничен ролями (RBAC), персональные данные маскируются, действия записываются в журнал аудита.

Роли, маскирование PII, аудит, квоты и safe-режим применяются к каждому запросу любого ассистента. Данные не покидают контур компании.

Один сервер на организацию

Шлюз спроектирован по модели «одна организация на развёртывание»: компания запускает собственный изолированный экземпляр со своей базой данных, и все участники команды подключаются к этому одному серверу.

• Многопользовательский. Много людей, у каждого свои токены и сессии, доступ разграничен RBAC.
• Мультибазовый. Один сервер обслуживает несколько информационных баз 1С одной организации (см. ниже).
• Не multi-tenant. Слоя изоляции между разными организациями нет, потому что каждая компания запускает свой экземпляр со своими данными. Размещение нескольких компаний на одном сервере не поддерживается.

На практике это означает:

• Одна установка = одна компания = одна база данных. Пользователи, API-токены, черновики, аудит и записи о базах 1С принадлежат одной организации.
• Изоляция между участниками команды строится на RBAC и владении объектами (например, черновики пользователя видны только ему), а не на tenant-скоупинге.
• Масштабирование на людей: выдать больше токенов и пригласить больше пользователей. Масштабирование на базы 1С: добавить записи подключений. Без отдельного control plane, один бинарник.

Путь запроса

AI-клиент обращается к шлюзу на endpoint POST /mcp. Каждый запрос обязан нести заголовок Authorization: Bearer ent_live_<...>; анонимный запрос получает 401. Поддерживаются два транспорта MCP:

• Streamable HTTP (предпочтительный): Accept: application/json
• HTTP+SSE (legacy): Accept: text/event-stream

Дальше запрос проходит политики шлюза: проверку роли и права на инструмент, лимиты частоты и гейты доступа. Успешный результат инструмента перед сериализацией проходит маскирование персональных данных (см. Маскирование PII и safe-режим), а каждый терминальный исход вызова инструмента записывается в аудит строкой mcp_tool_call со статусом, длительностью, размером входа и токеном.

Инструменты MCP

Шлюз отдаёт 13 бизнес-инструментов: 7 инструментов чтения, 4 инструмента записи и 2 инструмента просмотра собственных черновиков.

Запись только через черновики

Инструменты записи никогда не проводят документы в 1С напрямую: они создают черновики, которые проходят одобрение в веб-консоли. AI-клиент может просматривать только собственные черновики через list_my_drafts и get_draft; черновики одного участника приватны для него.

Несколько информационных баз

Один экземпляр шлюза может обслуживать несколько баз 1С одной организации. У каждой базы своя запись подключения с базовым URL, пользователем HTTP-Basic и, опционально, собственным зашифрованным паролем; у каждой свой пул соединений и circuit breaker, поэтому одна нестабильная база не тянет за собой остальные. Записи подключений управляются в разделе /web/admin/onec.

Как MCP-клиент выбирает базу:

• База по умолчанию. Активная запись подключения это база по умолчанию для чтения. Вызов read-инструмента без аргумента infobase идёт туда; для установки с одной базой поведение не меняется.
• Явный выбор. Read-инструменты принимают необязательный аргумент верхнего уровня infobase со значением идентификатора базы:

{ "name": "query_catalog",
  "arguments": { "infobase": "buh-prod", "type": "counterparty" } }

Неизвестный идентификатор возвращает понятную ошибку инструмента, бэкенд при этом не вызывается.

• Учётные данные по-базово, fail-closed. Каждая база расшифровывает свой пароль независимо. Ошибка расшифровки закрывает вызовы этой базы без отката на чужие учётные данные, соседние базы продолжают работать.

Важно про запись: путь записи (одобрение черновика с проведением в 1С) идёт в базу, закреплённую за черновиком. Черновик с явно выбранной базой (аргумент infobase) проводится в неё, а черновик без выбора базы проводится в базу по умолчанию, то есть в активное подключение из раздела /web/admin/onec. Отдельного подключения для записи в переменных окружения нет: адрес и учётные данные каждой базы берутся из её записи подключения. База по умолчанию меняется активацией нужной записи в /web/admin/onec, изменение вступает в силу без перезапуска сервиса.

Веб-консоль

Шлюз управляется из веб-консоли внутри контура компании: наблюдение, аудит, квоты и безопасность. Отдельным разделам консоли посвящены страницы трека: роли и доступ, маскирование PII и safe-режим, журнал аудита, наблюдаемость, квоты и уведомления, git-мост и AI-код-ревью.