Подключаем 1С к агентской среде через MCP. Полный гайд (вроде бы)

от автора

Я инженер-программист на небольшом российском заводе. Несмотря на скромные масштабы производства в штате имеется финансовый аналитик с постоянными потребностями в (внезапно) данных из учётной системы.
В сети я так и не нашёл более-менее полного гайда по подключению баз 1С к агентским средам через MCP. Встречаются отдельные статьи про Model Context Protocol (много), примеры для файловых систем, GitHub или PostgreSQL, но ничего про реальную интеграцию с 1С.

Поэтому решил собрать собственный опыт в одном месте.

В качестве платформы я использовал Hermes Agent, а в качестве MCP-сервера — расширение для 1С, работающее через стандартную HTTP-публикацию. Расширение взято отсюда: https://github.com/prepod2003/mcp-rsv-data. Несмотря на то, что все действия расширения ограничены чтением, решил, что агент подключается не к боевой базе, а к её ежедневно обновляемой копии. Немного паранойи не повредит.

Схема получилась простой:

Veeam Backup → ежедневое восстановление MS SQL → копия информационной базы 1С → HTTP-публикация 1С (IIS) → Hermes Agent

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

Восстановление базы

Для восстановления используется Veeam Backup & Replication 12.3 и модуль Veeam Explorer for Microsoft SQL Server.

 Import-Module Veeam.Backup.PowerShell -ErrorAction StopImport-Module Veeam.SQL.PowerShell -ErrorAction StopStart-Transcript 'C:\Scripts\Restore-SQL.log'# -----------------------------# Настройки# ----------------------------- $backupName   = '<имя бэкапа в Veeam B&R>'$sourceDatabase = '<имя исходной БД SQL>'$targetDatabase = '<имя целевой БД SQL>'$sqlServer    = '<адрес или FDQN целевого SQL сервера>'$sqlInstance  = '<инстанс (дефолтный MSSQLSERVER)'# опционально$sqlPort      = 1455# SQL Login, имеющий права sysadmin в формате Base64$sqlCred = Import-Clixml 'C:\creds\sql-cred.xml'# -----------------------------# Последняя точка восстановления# -----------------------------$backup = Get-VBRBackup -Name $backupName if (-not $backup) {    throw "Backup '$backupName' not found."}$restorePoint = Get-VBRApplicationRestorePoint -SQL |    Where-Object {        $_.Name -like '*<уникальная часть имени БД>*'    } |    Sort-Object CreationTime -Descending |    Select-Object -First 1if (-not $restorePoint) {    throw 'Restore point not found.'}# -----------------------------# SQL Restore Session# -----------------------------$session = Start-VESQLRestoreSession -RestorePoint $restorePointtry {     $database = Get-VESQLDatabase `        -Session $session `        -Name $sourceDatabase    if (-not $database) {        throw "Database '$databaseName' not found in restore point."    }    Restore-VESQLDatabase `        -Database $database `        -DatabaseName $targetDatabase `        -ServerName $sqlServer `        -InstanceName $sqlInstance `        -Port $sqlPort `        -SqlCredentials $sqlCred `        -Force `        -RecoveryState Recovery}finally {    Stop-VESQLRestoreSession -Session $session}Stop-Transcript

Первоначальная идея была после восстановления автоматически подгружать расширение .cfe в режиме Конфигуратора.

1cv8.exe DESIGNER/S кластер\имя_восстановленной_БД/N имя_пользователя_1С_с_админскими_правами/P пароль/LoadCfgExtension C:\1C\RSVData.cfe/UpdateDBCfg

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

Публикация HTTP-сервиса

MCP реализован стандартным HTTP-сервисом 1С, опубликованным через IIS. Фактически IIS принимает HTTP-запросы и передаёт их в rphost.exe, где уже выполняется код расширения.

Расширение не запускает отдельные процессы, не открывает соединения и не отправляет данные наружу. Код начинает выполняться только после входящего HTTP-запроса.

Для публикации базы через IISоткрываем 1С от имени Администратора в режиме Конфигуратора → Администрирование → Публикация на веб-сервере
Нам нужна закладка HTTP-сервисы и чек-бокс Публиковать HTTPсервисы расширений по умолчанию.

Hermes Agent

Hermes Agent устанавливается командой в Powershell: irm https://hermes-agent.nousresearch.com/install.ps1 | iex Модели подключены через агрегатора, используется openai/gpt-5.6-luna Hermes умеет работать с MCP «из коробки». Сервер добавляется одной командой:

hermes mcp add <имя MCP (я использую accounting)> --url http://<FDQN 1С сервера в локальной сети>/<имя опубликованной БД 1С>/hs/rsvdata/mcp --auth header

Во время настройки выяснился один нюанс.

Hermes ожидает Bearer-токен, а публикация 1С использует HTTP Basic Authentication. После добавления сервера пришлось вручную скорректировать конфигурацию.
Конфигурационные файлы Hermes Agent в Windows хранятся в C:\Users\<имя пользователя>\AppData\Local\hermes. Для Linux это ~/.hermes

В config.yaml получилось так:

mcp_servers:  <имя опубликованной БД 1С>:    url: http://<FDQN 1С сервера в локальной сети>/<имя опубликованной БД 1С>/hs/rsvdata/mcp    headers:      Authorization: Basic ${MCP_API_KEY}    enabled: true

А в .env хранится Base64-представление пары логин:пароль:
MCP_API_KEY=******************************==

Проверяем соединение в MCP в консоли:

hermes mcp test <имя MCP (accounting)>✓ Connected✓ Tools discovered: 8

Агент автоматически обнаруживает доступные инструменты MCP:

  • config

  • describe

  • get_structure

  • query

  • execute_query

  • reveal

  • help

  • ping

Как это выглядит в работе

После запуска Hermes Agent в CLI видны подключенные MCP:

В десктопной версии в левом меню Capabilities →MCP:

Теперь можно задавать вопросы обычным языком:

«Покажи последние реализации за август»

«Найди контрагента по ИНН»

«Какие документы продажи были оформлены вчера?»

«Кто не закупал продукцию больше года?»

Если информации о структуре недостаточно, агент сначала исследует конфигурацию (describe, get_structure), затем сам выбирает подходящий инструмент (query или execute_query) и возвращает результат.

Грабли

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

[ОРГ-1 229]

Из-за этого инструмент reveal не мог выполнить обратное преобразование, ибо ожидал строку без пробелов.

Полная очистка регистра анонимизации решила проблему. После повторного формирования карты новые токены стали создаваться корректно и декодирование снова заработало. Источник такого поведения локализовать не удалось, баг более не повторялся.

Итоги

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

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

Бонус: Настройка нескольких MCP для 1С

К Hermes Agent у меня подключены два MCP-сервера с разными информационными базами 1С: Бухгалтерия предприятия и 1С:ЗУП. С технической точки зрения они не отличаются: оба предоставляют одинаковый набор инструментов (describe, get_structure, query, execute_query и т.д.). Из-за этого агенту не всегда очевидно, к какой именно базе нужно обращаться.

Поэтому я сразу дал серверам понятные имена в конфигурации:

mcpServers:  accounting:    ...  wage:    ...

Этого показалось недостаточно. Если спросить просто «покажи сотрудников», агент может выбрать любую из баз, потому что справочник сотрудников существует и в бухгалтерии, и в ЗУП.

Чтобы исключить подобные ситуации, я добавил в SOUL.md описание назначения каждого MCP.

 ### accountingБаза 1С:Бухгалтерия предприятия.Использовать для:- реализации;- поступлений;- ОСВ;- проводок;- счетов;- НДС;- бухгалтерской и налоговой отчетности. ### wageБаза 1С:Зарплата и управление персоналом.Использовать для:- сотрудников;- кадровых документов;- отпусков;- больничных;- начислений;- удержаний;- графиков работы;- табелей.

Кроме выбора сервера, я зафиксировал общий порядок работы с инструментами 1С:

### General MCP rulesПри работе с MCP-серверами 1С придерживайся следующего порядка:1. Если структура объектов или доступные поля неизвестны, сначала используй describe и get_structure.2. Для типовых операций чтения используй query.3. Используй execute_query только если:   - требуемая выборка не поддерживается query;   - необходимы сложные соединения, агрегации или вычисления;   - требуется выполнить произвольный запрос на языке запросов 1С.4. Не используй execute_query, если задачу можно решить через query без потери функциональности.5. Не делай предположений о структуре конфигурации 1С.    Если состав реквизитов, табличных частей или связей неизвестен, сначала получи метаданные с помощью describe или get_structure. 

Смысл этих правил простой. Я не хочу, чтобы агент сразу начинал писать произвольные запросы к базе, опираясь на предположения о структуре конфигурации. Если он не знает состав реквизитов или регистров, сначала должен посмотреть метаданные через describe и get_structure. Для обычных выборок достаточно query, а execute_query остается инструментом для действительно сложных случаев, когда возможностей стандартного API уже недостаточно.

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

ссылка на оригинал статьи https://habr.com/ru/articles/1067524/