MCP-1C on-premise: где проходит сетевая граница

Главный вопрос при подключении AI к 1С звучит одинаково у всех: куда уйдёт код конфигурации и данные базы. Локальное размещение MCP-1C описывает место запуска сервера, а не весь путь данных. При работе с выгрузкой сервер читает файлы конфигурации и передаёт результаты AI-клиенту. Дальнейшая передача зависит от выбранной модели, клиента и включённых функций; доступ к живой базе требует отдельного подключения к 1С. Это различие важно и для Открытой редакции.

Почему запуск локальный по самой архитектуре

Транспорт MCP по умолчанию это stdio: AI-клиент запускает бинарник как подпроцесс на вашей машине и общается с ним через stdin и stdout. Отдельные порты и HTTP-серверы для этого не нужны. Это не наше изобретение, а базовый режим протокола. В спецификации MCP сказано прямо: клиент запускает MCP-сервер как подпроцесс, сервер читает JSON-RPC из стандартного ввода и пишет в стандартный вывод. Клиентам рекомендовано поддерживать stdio где это возможно.

Практический вывод: процесс mcp-1c-advanced или mcp-1c-pro живёт ровно столько, сколько открыт ваш AI-клиент. Это отдельный процесс на вашей машине, обмен с клиентом идёт через stdin и stdout, он работает как локальная программа. Один stdio-процесс обслуживает ровно одного пользователя. Сам канал stdio не открывает слушающий сокет для MCP-клиентов. Это не исключает сетевые соединения других включённых компонентов.

Отдельно про флаг --listen: встроенный HTTP-сервер это только транспорт длинного опроса для связи с 1С, а не сетевой MCP-сервер для внешнего доступа. Он нужен для подключения к платформе, а не для того, чтобы выставить инструменты наружу.

Что значит on-premise в Открытой редакции

Чтение локальной выгрузки в Открытой редакции не требует отправки её файлов внешней модели самим механизмом чтения. Это не обещание офлайн-работы всей цепочки: запросы к живой базе используют настроенное подключение к 1С, а модель получает контекст через AI-клиент. Расширение конфигурации Открытой редакции работает только на чтение: оно не изменяет данные и конфигурацию. То есть в этой редакции в принципе нет операций записи, которые могли бы что-то поменять в базе.

Локальность нашего сервера и локальность самого AI это разные вещи:

• При работе с локальной выгрузкой MCP-сервер читает файлы с диска и возвращает контекст клиенту.
• AI-клиент использует выбранную модель. Если она размещена во внешнем сервисе, передача ей контекста — отдельный сетевой этап.

Граница проходит ровно по этому стыку. Метаданные и фрагменты кода, которые вы передаёте в запрос, отправляет AI-клиент в свою модель по своим правилам. MCP-1C решает за вас задачу локального чтения конфигурации, а политику работы облачной модели определяет ваш клиент. Для закрытого контура нужно проверить всю цепочку: размещение модели, поведение клиента, подключение к 1С, включённые функции и дополнительные сервисы. Одного локального запуска MCP недостаточно.

Сетевые обращения платных редакций

Расширенная и Профессиональная редакции периодически проверяют лицензию через интернет. Это про лицензию, а не про данные 1С. Локальный запуск сервера не отменяет эти обращения. Связь AI-клиента с моделью и обращения включённых функций рассматриваются отдельно.

Как устроена лицензия:

1. Ключ активируется один раз.
2. Лицензия хранится локально и проверяется периодически.
3. Идентичность лицензии лежит в каталоге конфигурации как файл. Отдельной переменной окружения для подмены идентификатора нет, и это локальный файл, а не запрос к серверу при каждом старте.

Активацию можно перенести между машинами: --activate на новой машине занимает слот устройства и сама освобождает прежний. Команда --deactivate освобождает слот, когда ключ больше нигде не нужен. Обе команды запускаются на вашей машине, но обращаются к лицензионному серверу.

Ещё одно сетевое обращение платных редакций это самообновление. Команда --update идёт через лицензионный сервер: запрос авторизуется лицензионным ключом и идентификатором машины, а перед заменой бинарника проверяется криптографическая подпись Ed25519 скачанного файла. С данными 1С это не связано.

Ниже перечислены отдельные операции сервера, а не полный перечень сетевого обмена клиента, модели и подключений:

LLM-функции сервера и внешние обращения

К внешнему LLM-провайдеру обращаются четыре функции Профессиональной редакции: автогенерация документации (--build-autodoc), генерация тестов (--build-testgen), генерация .epf обработок (--build-epfgen) и навигация по типовым конфигурациям (--build-typicalconfigs). По умолчанию они отправляют фрагменты кода и метаданных выбранному провайдеру, чтобы обогатить результат. Поддерживаются два провайдера:

• YandexGPT, по умолчанию, флаг --autodoc-provider yandexgpt, ключи YANDEXGPT_API_KEY и YANDEXGPT_FOLDER_ID.
• GigaChat, флаг --autodoc-provider gigachat, ключи GIGACHAT_CLIENT_ID и GIGACHAT_CLIENT_SECRET.

Учётные данные читаются из переменных окружения. Если они не заданы, автогенерация документации завершается с ошибкой, а генерация тестов, сборка .epf и индекс типовых конфигураций продолжают работу без LLM. У этих трёх функций обращение к LLM можно и отключить явно, и тогда они работают на вашей машине:

• --testgen-llm-disable: генерация только скелетов тестов без LLM-комментариев.
• --epfgen-llm-disable: сборка бандлов .epf без LLM-обогащения.
• --typicalconfigs-llm-disable: индекс подсистем без описаний.

У автогенерации документации отдельного флага отключения нет: она полностью построена на ответах модели и без API-ключей не запускается.

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

Конфигурация локального запуска

Минимальный конфиг для запуска по stdio на примере Claude Desktop. AI-клиент сам запускает бинарник как подпроцесс на вашей машине. В этом примере сервер обращается к HTTP-сервису 1С по указанному адресу; размещение модели этим конфигом не определяется.

{
  "mcpServers": {
    "mcp-1c": {
      "command": "/usr/local/bin/mcp-1c-advanced",
      "args": [
        "--base", "http://localhost:8080/acc/hs/mcp-1c",
        "--user", "Администратор",
        "--password", ""
      ]
    }
  }
}

Путь к файлу конфигурации зависит от ОС:

Бинарник один, без внешних зависимостей, Docker для обычной работы не нужен. Поддерживаются Windows, macOS и Linux на amd64 и arm64, совместимость с 1С версий 8.3.x и 8.5.x.

Запись в базу: только в платных и только с подтверждением

В Открытой редакции записи нет вовсе. Расширенная редакция добавляет выполнение кода через sandbox с подтверждением и аудит-логом. То есть запись возможна только в платных редакциях и только при явном подтверждении операции, а не молча по инициативе модели.

Корпоративный шлюз и сетевая граница

Корпоративный шлюз разворачивается в инфраструктуре компании и управляет подключениями, ролями, настраиваемым маскированием и аудитом. Его размещение само по себе не делает локальными выбранную модель и дополнительные интеграции. Маскирование зависит от правил и формата данных; сетевую границу проверяют для конкретной установки. Обзор корпоративного шлюза.

Коротко про границу

Локальные файлы, подключение к 1С, MCP-клиент, модель и дополнительные функции образуют разные участки обмена. Настройки каждого из них определяют, какие данные и куда передаются. On-premise описывает размещение компонента, но не гарантирует отсутствие внешних соединений всей системы. Подробности по редакциям и инструментам собраны в документации, сравнение и цены на странице тарифов, а начать можно с главной.