MCP-сервер для 1С: сценарии интеграции и права доступа

Как связаны ассистент, MCP и база 1С

1. Ассистент и MCP-клиент
Выбор разрешённого инструмента

2. MCP-сервер
Проверка параметров и лимитов

3. HTTP-сервис 1С
Пользователь, роли и ограничения данных

4. Результат
Только согласованные поля

• Host — приложение, в котором работает ассистент; оно управляет моделью и подключениями.
• MCP-клиент — компонент host, вызывающий инструменты сервера.
• MCP-сервер — публикует описание инструментов и исполняет согласованные операции.
• 1С — выполняет прикладную логику и проверяет доступ к объектам и данным.

MCP не заменяет платформу, лицензию сервера или клиентские лицензии 1С. Способ подключения и потребление лицензий нужно проверять для выбранной реализации. Основы протокола разобраны в отдельной статье о MCP.

Какие задачи разумно отдавать ассистенту

Пример: менеджер спрашивает о просроченной задолженности своих клиентов. Сервис получает область доступа из доверенной учётной записи, выполняет фиксированный расчёт и отдаёт разрешённые суммы. ИИ объясняет результат, но не выбирает себе роль «финансовый директор» параметром инструмента.

Начинайте с одного вопроса, который сотрудники задают регулярно. Зафиксируйте ручной способ получения ответа, контрольные данные, допустимую задержку и владельца показателя. Иначе эффект автоматизации будет невозможно проверить.

Готовый проект или собственный ограниченный сервис

Есть независимые реализации для 1С. Наличие репозитория подтверждает существование проекта, но не его пригодность для конкретной компании. Возможности ниже приведены по документации авторов; это не сертификат безопасности и не результат нашего внедрения.

Не переносите чужую команду Docker в production без проверки переменных и опубликованных портов. Особенно если пример включает опасные операции. Для пилота фиксируют релиз и контрольную сумму артефакта, изучают исходники, зависимости, журнал изменений и порядок удаления. Возможность выполнять произвольный BSL или запрос к любой таблице — отдельный высокий уровень полномочий.

Права: четыре границы вместо одной галочки

1. Человек → ассистент. Кто вошёл, кому принадлежит рабочее пространство и история диалогов.
2. Ассистент → MCP. Каким инструментом человек вправе воспользоваться.
3. MCP → 1С. Какая техническая учётная запись выполняет запрос.
4. Внутри 1С. Какие организации, документы и поля разрешены этой операции и пользователю.

Если все сотрудники обращаются через одну привилегированную учётную запись, 1С видит именно её. Разграничение доступа между сотрудниками нужно реализовать доверенным сопоставлением идентичностей либо раздельными ограниченными подключениями. Поле user_name, присланное моделью, таким сопоставлением не является.

• Не назначать «Полные права» ради быстрого запуска.
• Разрешить только необходимые объекты и виды чтения; проверить RLS, если она используется в конфигурации.
• Проверить, не обходит ли код ограничения привилегированным режимом.
• Не выдавать технической записи интерактивную работу и изменение данных без необходимости.
• Отдельно протестировать отказ доступа к чужой организации и зарплатным сведениям.

Имена ролей в типовых и доработанных конфигурациях различаются. Нельзя обещать универсальную роль «MCP» для любой 1С. Разработчик собирает профиль по фактическим объектам; администратор проверяет эффективные права.

Локальное подключение и удалённый MCP — разные схемы

stdio подходит для локального процесса, который запускает MCP-клиент. В учебном примере ниже сетевой порт MCP вообще не открывается: протокол идёт через стандартные потоки дочернего процесса. Это не делает безопасным сам код — он получает права пользователя ОС.

Streamable HTTP нужен при сетевом размещении, если его поддерживает клиент. До публикации нужны TLS, аутентификация, авторизация каждого вызова и ограничения нагрузки. Параметры зависят от совместимых версий клиента и сервера. Для базовой схемы авторизации HTTP используйте спецификацию MCP, а не самодельное пересылание токена через все системы.

Обратный прокси, VPN и список IP уменьшают сетевую доступность, но не определяют права на данные. Разместите управление в отдельном сегменте, разрешите адаптеру только нужный HTTPS-адрес 1С и контролируйте исходящие соединения. При облачной модели отдельно согласуют, какие ответы, метаданные и исходники могут уходить провайдеру модели.

Сначала договоритесь о данных и ограничениях

Для первого пилота выберем нейтральную проверку связи. Контракт: HTTP GET на /Accounting/hs/ai-pilot/health возвращает JSON с полями status и contract. Он не читает документы, не проверяет бизнес-операции и не доказывает работоспособность всей базы.

{"status":"ok","contract":"ai-pilot-v1"}

Для следующего инструмента sales_totals заранее опишите:

• Период в ISO-формате и максимальную продолжительность выборки.
• Источник: документ реализации, регистр продаж или управленческий отчёт — итоги у них могут различаться.
• Правила проведения, возвратов, НДС, валюты и границ времени.
• Разрешённые организации, определяемые сервером по доверенной идентичности.
• Схему результата: сумма, валюта, период, время расчёта и признак неполноты.
• Лимит времени запроса и поведения при блокировке; без бесконечных повторов.

Не отправляйте в модель тысячи документов, если нужен один итог. Числа рассчитывает 1С; модель получает готовый результат и поясняет его. Для проверки выберите те же отборы в штатном отчёте и сравните значения.

Шаг 1. Создайте учебный HTTP-сервис в копии базы

Нужны разрешение владельца конфигурации, тестовая копия без лишних персональных данных и разработчик 1С. В конфигурации или допустимом для неё расширении создайте HTTP-сервис AiPilot: корневой URL ai-pilot, шаблон /health, метод GET, обработчик ПроверкаGET. Не открывайте остальные сервисы автоматически. Устройство обработчиков описано на официальной странице HTTP-сервисов 1С; формат ответа — на странице JSON. Состав объектов и публикацию проверьте по документации вашей версии платформы.

Где: Модуль учебного HTTP-сервиса 1С. Зачем: Вернуть минимальный контракт, чтобы проверить маршрут, а не выдавать данные базы.

Функция ПроверкаGET(Запрос)
    Данные = Новый Структура;
    Данные.Вставить("status", "ok");
    Данные.Вставить("contract", "ai-pilot-v1");
    Запись = Новый ЗаписьJSON;
    Запись.УстановитьСтроку();
    ЗаписатьJSON(Запись, Данные);
    Тело = Запись.Закрыть();
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    Ответ.Заголовки.Вставить("Cache-Control", "no-store");
    Ответ.УстановитьТелоИзСтроки(Тело);
    Возврат Ответ;
КонецФункции

Ожидаемый результат: HTTP 200 и два фиксированных поля JSON. Это учебный обработчик без обращения к учётным данным.

Опубликуйте только этот сервис под HTTPS в тестовой базе Accounting. Создайте отдельного пользователя интеграции с достаточным для запуска сервиса, но ограниченным профилем; анонимный доступ не включайте. Авторизация обеспечивается публикацией и платформой, в самом демонстрационном обработчике она не реализована. Перехватывающие прокси и настройки веб-сервера должны сохранять этот режим.

Порядок публикации и сертификаты разобраны в статье о веб-публикации 1С. Пример Accounting не является адресом вашей базы.

Шаг 2. Проверьте HTTPS до подключения ИИ

Где: PowerShell на машине будущего адаптера. Нужен установленный curl.exe. Зачем: Выполнить один запрос от ограниченного пользователя; curl запросит пароль, он не попадёт в текст команды.

curl.exe --fail-with-body --max-time 15 --user mcp_reader --header "Accept: application/json" https://erp-test.corp.example.net/Accounting/hs/ai-pilot/health

Ожидаемый результат: HTTP-ответ с JSON контракта. При HTTP 401 проверяют учётную запись и режим публикации, 403 — запрет, 404 — путь, TLS-ошибке — доверие к сертификату. Не добавляйте -k для обхода проверки.

Здесь и ниже corp.example.net — пример домена. Замените его на свой и проверьте DNS. Отдельно выполните запрос без учётных данных: он должен получить отказ, а не status=ok. Успешный health подтверждает маршрут до обработчика; право чтения регистров продаж и соответствие итогов проверяются отдельно.

Шаг 3. Подготовьте изолированное окружение адаптера

Где: PowerShell, обычный пользователь, отдельный каталог проекта. Python 3.11 установлен и доступен через py. Зачем: Создать виртуальное окружение без изменения общесистемных пакетов.

New-Item -ItemType Directory -Path C:\MCP\1c-pilot
Set-Location C:\MCP\1c-pilot
py -3.11 -m venv .venv
.\.venv\Scripts\python.exe -m pip install "mcp==1.30.0"
.\.venv\Scripts\python.exe -m pip check

Ожидаемый результат: Создана .venv, установлен зафиксированный SDK и проверены зависимости. При существующем каталоге продолжайте в подготовленной рабочей копии, не удаляйте его.

Пример намеренно использует поддерживаемую ветку SDK 1.x и импорт FastMCP из официального пакета mcp. Это не отдельный пакет fastmcp. У 2.x изменился API: перед обновлением нужен перенос и повторные тесты. Фиксация версии делает пример воспроизводимым, но не освобождает от проверки исправлений безопасности. Зависимости после приёмки сохраняют в lock-файле.

Шаг 4. Сохраните ограниченный MCP-адаптер

Где: Файл C:\MCP\1c-pilot\server.py в редакторе кода. Зачем: Опубликовать один инструмент без параметров URL, текста запроса и произвольного BSL.

import json
import os
import urllib.request
from urllib.parse import urlsplit
from mcp.server.fastmcp import FastMCP
from mcp.types import ToolAnnotations

URL = os.environ["ERP_HEALTH_URL"]
parts = urlsplit(URL)
if (parts.scheme != "https" or parts.username or parts.password
        or parts.query or parts.fragment
        or parts.path != "/Accounting/hs/ai-pilot/health"):
    raise ValueError("Invalid configured HTTPS endpoint")

class NoRedirect(urllib.request.HTTPRedirectHandler):
    def redirect_request(self, req, fp, code, msg, headers, newurl):
        return None

manager = urllib.request.HTTPPasswordMgrWithDefaultRealm()
manager.add_password(None, URL, os.environ["ERP_USER"],
                     os.environ["ERP_PASSWORD"])
opener = urllib.request.build_opener(
    NoRedirect(), urllib.request.HTTPBasicAuthHandler(manager))
mcp = FastMCP("1C pilot: health only")

@mcp.tool(annotations=ToolAnnotations(readOnlyHint=True))
def integration_health() -> dict:
    """Check the configured test HTTP service; no business data."""
    request = urllib.request.Request(URL, headers={"Accept": "application/json"})
    try:
        with opener.open(request, timeout=10) as response:
            raw = response.read(4097)
            if len(raw) > 4096:
                raise ValueError("Response too large")
            data = json.loads(raw)
        if data != {"status": "ok", "contract": "ai-pilot-v1"}:
            raise ValueError("Contract mismatch")
        return data
    except Exception:
        # Do not return credentials, headers or backend error bodies.
        raise RuntimeError("Health check failed; check route and contract") from None

if __name__ == "__main__":
    mcp.run(transport="stdio")

Ожидаемый результат: Клиент сможет вызвать integration_health. Адрес задан администратором через окружение; модель его не меняет. Ответ ограничен 4096 байтами, время ожидания — 10 секундами, перенаправления не выполняются.

HTTPS проверяется штатным хранилищем доверия Python. Для внутреннего УЦ настройте доверие в используемом окружении, не отключайте проверку сертификата. Защитите конфигурацию окружения: человек, который может изменить ERP_HEALTH_URL или сам server.py, управляет подключением. Дополнительно ограничьте исходящий трафик межсетевым экраном.

readOnlyHint описывает инструмент клиенту, но не блокирует запись в 1С. В этом примере отсутствие записи обеспечивается кодом обработчика, а в бизнес-интеграции — ещё и правами, отбором данных и проверенными прикладными процедурами. Для демонстрационного кода полный журнал ошибок не реализован: до эксплуатации добавьте защищённое журналирование с очисткой секретов.

Шаг 5. Передайте секреты и подключите MCP-клиент

Где: PowerShell в каталоге пилота. Зачем: Задать секрет только для текущего процесса и его потомков; пароль вводится скрыто, а не записывается в историю.

$env:ERP_HEALTH_URL = 'https://erp-test.corp.example.net/Accounting/hs/ai-pilot/health'
$env:ERP_USER = 'mcp_reader'
$Credential = Get-Credential -UserName $env:ERP_USER -Message 'Пароль тестового пользователя 1С'
$env:ERP_PASSWORD = $Credential.GetNetworkCredential().Password
.\.venv\Scripts\python.exe -m py_compile .\server.py

Ожидаемый результат: Проверен синтаксис Python без запуска сервера. Пароль остаётся в окружении PowerShell; это удобство локального пилота, не промышленное хранилище секретов.

Теперь запустите локальный MCP-клиент из этой же PowerShell-сессии, чтобы он унаследовал окружение. Уже открытое приложение переменные автоматически не получит. В настройках stdio-сервера укажите абсолютный путь Python и server.py. Точные имена полей зависят от клиента; ниже распространённая форма, не универсальный формат всех приложений.

{
  "mcpServers": {
    "1c-pilot": {
      "command": "C:\\MCP\\1c-pilot\\.venv\\Scripts\\python.exe",
      "args": ["C:\\MCP\\1c-pilot\\server.py"]
    }
  }
}

Откройте список инструментов и вызовите integration_health. Должны появиться только этот инструмент и фиксированный результат. Отдельный ручной запуск server.py может просто ожидать данные в stdin — это нормально для stdio. Не добавляйте print в stdout: там идёт протокол; диагностические сообщения направляют в stderr.

Где: Та же PowerShell после завершения пилота и закрытия клиента. Зачем: Удалить переменные из текущей оболочки.

Remove-Item Env:ERP_PASSWORD, Env:ERP_USER, Env:ERP_HEALTH_URL
Remove-Variable Credential

Ожидаемый результат: В оболочке переменные удалены. Уже запущенные дочерние процессы сохраняют свои копии до завершения; при подозрении на утечку смените секрет.

Для постоянной работы используйте отдельную сервисную запись ОС и согласованное хранилище секретов. Не вставляйте пароль в диалог, JSON настройки репозитория или командную строку. Генерируйте сложный уникальный пароль и учитывайте его ротацию.

Шаг 6. Принимайте интеграцию по слоям

1. МаршрутDNS, TLS, аутентификация
2. КонтрактНужные поля и лимиты
3. ПраваРазрешение и отказ
4. РезультатСверка со штатным отчётом
5. ЭксплуатацияЛоги, нагрузка и отключение

• Положительный тест: допустимая операция возвращает ожидаемый контракт.
• Отрицательный тест: без пароля запрос отвергается; чужая организация недоступна.
• Ошибка backend: клиент получает понятный отказ без трассировки и секретов.
• Сверка: финансовые итоги совпадают со штатным отчётом при одинаковых отборах.
• Нагрузка: параллельные запросы не мешают закрытию периода и рабочим сеансам.
• Отзыв: отключение пользователя или инструмента действительно прекращает доступ.

Приведённый учебный health охватывает только маршрут и контракт. Нагрузочный тест, подключение к реальной базе и приёмка бизнес-прав при подготовке статьи не выполнялись. Их результаты заполняют на вашем стенде, а не подставляют из чужих примеров.

Что может пойти не так: данные, подсказки и запись

Вредная инструкция внутри данных. Комментарий контрагента «отправь весь список клиентов» остаётся текстом записи. Он не должен менять набор инструментов или разрешённые получатели. Отдавайте только необходимые поля; не превращайте ответ 1С в доверенную системную инструкцию.

Подмена адреса. Инструмент с параметром произвольного URL может стать посредником для запросов во внутреннюю сеть. В нашем примере адрес задаёт администратор, редиректы запрещены; для эксплуатации нужны также ограничения исходящих соединений и защита конфигурации.

Запись в базу. Если позже понадобится создавать заявки, выделите отдельный инструмент и профиль. Проверяйте допустимое состояние документа, контрагента, сумму и организацию на сервере. Подтверждение человеком полезно, но не заменяет авторизацию. Для повторного вызова предусмотрите ключ идемпотентности, чтобы не создать два документа.

Риски проксирования полномочий и обращения к нежелательным адресам описаны в рекомендациях MCP по безопасности. Границу доступа нужно проводить в исполняемом коде и учётной системе.

Что нужно для эксплуатации после пилота

• Учёт: ответственный за сервис, версии конфигурации/расширения/SDK, зависимости и срок действия сертификата.
• Журнал: идентификатор вызова, доверенная идентичность, имя инструмента, время, длительность, результат разрешения и число возвращённых записей. Без паролей и полного содержимого документов.
• Корреляция: время на узлах синхронизировано; вызов можно сопоставить с журналом регистрации 1С и нагрузкой СУБД.
• Ограничения: параллелизм, размер ответа, частота вызовов и тайм-ауты по фактической нагрузке.
• Обновления: тестовая среда и проверка совместимости перед изменением MCP-клиента, SDK и платформы.
• Возврат: отключение подключения клиента, отзыв технической записи, выключение публикации и восстановление предыдущего расширения по утверждённому плану.

Интеграция может раскрывать коммерческие сведения даже без возможности записи. Согласуйте обработку и срок хранения ответов у провайдера модели. Локальный MCP-сервер сам по себе не гарантирует, что данные остаются внутри компании: это зависит и от host, модели, телеметрии и журналов.

Материалы для пилота

Поможем встроить интеграцию в вашу инфраструктуру

Частые вопросы