MCP сервер к 1С через Claude Code, кто реально завёл на проде

[joncez]

Хочу прикрутить MCP сервер чтобы агент мог дёргать данные из нашей 1С и базы напрямую, а не я ему вручную выгрузки копипастил. По докам всё красиво, но интересует кто реально завёл MCP не в демке а на боевой инфре, с правами доступа, и не словил при этом что агент полез не туда. Особенно про связку с 1С и российскими СУБД, потому что примеры все про postgres и github, а у нас зоопарк.

[elixir2010]

@joncez, завёл MCP к нашему postgres реплике (только чтение!) месяц назад. ключевое слово только чтение, отдельный юзер бд с грантом select и всё. агенту вообще нельзя давать ничего что может писать, рано или поздно он что нибудь сделает

[qawsqaws]

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

[theopal]

агенту вообще нельзя давать ничего что может писать, рано или поздно он что нибудь сделает

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

[b1llyn0m]

Расскажу как у нас это устроено, гоняем в проде три месяца на связке 1С плюс postgres плюс отдельный сервис.

Архитектурно агент НИКОГДА не ходит в боевые данные напрямую. Между ним и базой стоит свой MCP сервер на питоне, который выставляет не таблицы а конкретные именованные операции: получить остатки по складу, найти контрагента по инн, выгрузить движения за период. Внутри каждой операции уже захардкожен безопасный запрос с лимитами. Агент не может написать произвольный sql, он может только вызвать то что мы разрешили. Это снимает 90 процентов страха.

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

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

Про российские субд: если у вас не postgres а что то типа постгрес про или ред база данных, протокол тот же, драйвер psycopg ложится без проблем, ничего экзотического. С самой 1С возни больше из-за её http-сервисов и аутентификации, закладывайте пару дней только на то чтобы стабильно ходить под сервисным пользователем и не ловить разрывы сессии.

Итого: не давай агенту базу, давай ему набор безопасных кнопок. Тогда MCP на проде это нормально, а не русская рулетка.

[bruce01]

@elixir2010, @автор всё что выше написали про только чтение и прослойку правильно, но добавлю про токены. MCP который отдаёт сырые таблицы будет жрать контекст как не в себя, агент прочитает 500 строк выгрузки и захлебнётся. отдавай агрегаты и top-N, не сырьё

[artgold]

@b1llyn0m, холивар конечно но MCP это переусложнение для большинства задач. я просто положил агенту в репо скрипты выгрузки, он их запускает через bash и читает результат. никакого отдельного сервера, никакого протокола, работает и отлаживается элементарно. MCP оправдан когда инструментов реально много и их шарят между проектами

[hunter22]

я просто положил агенту в репо скрипты выгрузки, он их запускает через bash и читает результат

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