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

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

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

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

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

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 Stop
Import-Module Veeam.SQL.PowerShell -ErrorAction Stop
Start-Transcript 'C:ScriptsRestore-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:credssql-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 1
if (-not $restorePoint) {
    throw 'Restore point not found.'
}
# -----------------------------
# SQL Restore Session
# -----------------------------
$session = Start-VESQLRestoreSession -RestorePoint $restorePoint
try {
     $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:1CRSVData.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<имя пользователя>AppDataLocalhermes. Для 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 ^[2] описание назначения каждого 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 ^[2], и дальше агент применяет их автоматически практически во всех задачах, связанных с 1С.