Как подключить MCP-клиент к 1С через защищённый прокси

Администратор подключил MCP-клиент к опубликованной базе. Запрос POST дошёл до веб-сервера, получил перенаправление и вернулся в 1С как GET. Причина — одна прописная буква в имени публикации.

В рекомендуемой схеме проекта 1c_mcp участвуют MCP-клиент, Python-прокси и опубликованный HTTP-сервис 1С. Задача — открыть клиенту один инструмент, сохранить аутентификацию 1С и не выдать тестовой учётной записи лишние права.

Ниже — схема для тестового контура. Вы установите готовое расширение, опубликуете сервис и запустите прокси в Docker. Разработку конфигурации и настройку языковой модели оставим за рамками инструкции.

Для рабочего контура ставьте прокси

Проект 1c_mcp поддерживает два маршрута. Клиент подключается прямо к HTTP-сервису 1С либо работает через Python-прокси.

Для прямого подключения документация 1c_mcp требует отключить аутентификацию 1С. Реквизиты записывают в default.vrd. Авторы проекта считают такую схему небезопасной.

Прокси сохраняет аутентификацию на веб-сервере. На входе он принимает OAuth2, а в 1С передаёт реквизиты через Basic Auth. Через прокси также подключаются клиенты, которым нужен транспорт stdio.

Для рабочего контура выбирайте прокси. Прямой маршрут оставьте для изолированной проверки без рабочих данных и доступа из общей сети.

Что разместить рядом с 1С

Проект 1c_mcp состоит из расширения 1С и опционального Python-прокси. Расширение публикует данные и функции базы для MCP-клиента.

Готовый файл лежит в build/MCP_Сервер.cfe. В расширение входит HTTP-сервис mcp_APIBackend, который нужно добавить в веб-публикацию. Код Python-прокси находится в src/py_server/.

Эта схема задаёт состав внутренних компонентов: расширение 1С, веб-публикация и Python-прокси. Сам MCP-клиент подключается к прокси либо напрямую к опубликованному сервису.

Требования к серверу 1С зависят от нагрузки информационной базы. Их можно сверить с требованиями к серверу 1С. Ресурсы для локальной модели считайте отдельно по документации выбранной модели.

Сначала подготовьте тестовую базу

Первое подключение выполняйте на отдельном контуре. Создайте пользователя под один проверяемый сценарий и выдайте ему только нужные права.

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

Для первого запуска возьмите готовый инструмент из расширения. Затем определите, какие объекты 1С нужны этому инструменту. Для чтения остатков не требуются права на изменение документов или доступ к зарплатным данным.

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

Установите расширение и опубликуйте HTTP-сервис

Скачайте репозиторий 1c_mcp и возьмите файл build/MCP_Сервер.cfe. Подключите его к тестовой базе через штатное управление расширениями.

Затем добавьте HTTP-сервис mcp_APIBackend в веб-публикацию. Адрес сервиса строится по такому шаблону:

https://server.example/ИмяПубликации/hs/mcp/

Регистр букв в URL должен совпадать с именем публикации. Документация 1c_mcp предупреждает: несовпадение вызывает перенаправление, после которого запрос POST может превратиться в GET.

Скопируйте имя из настроек публикации и вставьте его в URL. Не набирайте адрес по памяти: TradeBase и tradebase для этой схемы не одно и то же.

Аутентификацию 1С оставьте включённой. Реквизиты передаст Python-прокси через Basic Auth.

Поднимите Python-прокси в Docker

Перейдите в каталог src/py_server/. Параметры запуска сверяйте с документацией установленной версии 1c_mcp: проект продолжает развиваться.

Создайте файл окружения из примера:

cp.env.docker.example.env

Запишите в .env адрес опубликованного HTTP-сервиса. Сетевое имя должно разрешаться с узла, где работает Docker.

Если Docker и 1С запущены на одном хосте, не указывайте localhost. Внутри контейнера это имя ведёт к самому контейнеру. Документация проекта предписывает использовать host.docker.internal:

MCP_ONEC_URL=http://host.docker.internal/ИмяПубликации/hs/mcp/

Ещё раз сравните регистр имени публикации. Затем запустите прокси:

docker-compose up -d

Команда создаст и запустит контейнеры из конфигурации Docker Compose. Реквизиты и режим авторизации задайте по документации в src/py_server/.

Подключите MCP-клиент

Готовые примеры настроек лежат в каталоге mcp_client_settings/ проекта 1c_mcp. Выберите конфигурацию для своего клиента, затем подставьте адреса и параметры доступа.

Клиенту с HTTP-подключением укажите адрес Python-прокси. Если приложение требует stdio, возьмите команду запуска из соответствующего примера. Прямой HTTP-сервис 1С транспорт stdio не поддерживает.

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

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

Четыре сбоя первого запуска

Проверяйте связку по компонентам. Начните с адреса публикации, затем переходите к прокси и клиенту. Так ошибка URL не смешается с неверным транспортом или реквизитами.

Проверка сверху вниз быстрее локализует сбой. Если запрос не дошёл до HTTP-сервиса, настройки инструмента в расширении пока ни при чём.

Выберите режим авторизации под задачу

Python-прокси поддерживает два режима: фиксированного пользователя и проброс аутентификации. Выбор зависит от того, под чьей учётной записью клиент должен обращаться к 1С.

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

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

Не выдавайте тестовому пользователю полные права ради успешного подключения. Сначала определите объект, к которому обращается инструмент, затем откройте доступ к этому объекту.

Откройте модели один инструмент

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

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

Результат должен соответствовать данным, доступным этому пользователю в обычном клиенте 1С. Расхождение указывает на ошибку в правах, выбранной учётной записи или настройке подключения.

Собственные инструменты добавляют через обработку 1С. Обработку включают в подсистему mcp_КонтейнерыИнструментов. Модуль менеджера должен экспортировать два метода:

ДобавитьИнструменты(Инструменты)
ВыполнитьИнструмент(ИмяИнструмента, Аргументы)

Руководство по разработке лежит в src/1c_ext/agents.md. Там же описаны инструменты, ресурсы и промпты на стороне 1С.

Проверка перед переносом в рабочий контур

Рекомендуемый маршрут проекта связывает клиент, Python-прокси и опубликованный сервис:

MCP-клиент
→ Python-прокси
→ HTTP-сервис 1С
→ расширение 1c_mcp

Прокси принимает OAuth2 на стороне MCP. При обращении к опубликованному сервису 1С он передаёт реквизиты через Basic Auth.

Перед переносом проверьте связку на тестовой базе:

• расширение MCP_Сервер.cfe подключено;
• сервис mcp_APIBackend входит в веб-публикацию;
• регистр имени публикации совпадает с URL;
• в MCP_ONEC_URL записан адрес, доступный контейнеру;
• клиент использует поддерживаемый транспорт;
• тестовый пользователь видит только нужные ему объекты;
• готовый инструмент возвращает ожидаемые тестовые данные.

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