MCP-серверы для вайб-кодинга в 1С между совместимостью и рисками

Ниже это разбирает интеграционный архитектор, а не маркетолог протокола: задача читателя простая и жёсткая, не пообещать системе совместимость, которую ты не проверил. В тексте собрана карта «система-протокол-полномочие-статус» и правило трёх статусов, по которому каждую связку можно отнести к подтверждённой, адаптируемой или непроверенной. Подключать можно только первую категорию.

Совпадение термина MCP между двумя системами говорит лишь о том, что обе умеют говорить по протоколу Model Context Protocol. Оно ничего не говорит о том, какой транспорт используется, какие полномочия выданы и что случится при отказе канала. Именно эти три вещи, а не бренд MCP, решают, безопасно ли подключение.

Начнём с транспорта, потому что от него зависит модель прав. Спецификация MCP (modelcontextprotocol.io, доступ 2026-07-18) определяет ровно два стандартных клиент-серверных транспорта: stdio (подпроцесс через stdin/stdout) и Streamable HTTP. Клиенты, по формулировке спецификации, SHOULD поддерживать stdio, когда это возможно. Уже отсюда следует неудобный вывод: «поддержка MCP» сама по себе не сообщает, какой транспорт, а значит и какую модель разрешений, использует конкретная пара «клиент-система».

Дальше идёт авторизация. По странице авторизации (это текущая черновая, draft-редакция спецификации на 2026-07-18) авторизация в MCP OPTIONAL. HTTP-транспорты SHOULD идти по потоку OAuth 2.1, а stdio-транспорты SHOULD NOT следовать этой спецификации вообще и вместо этого берут учётные данные напрямую из локального окружения. Практический смысл: «подтверждённое» stdio-подключение и «подтверждённое» HTTP-подключение проверены против структурно разных механизмов прав, а не против одного и того же. Нельзя перенести доверие с одного на другой.

Есть и протокольный режим отказа, не зависящий от вендора. В разделе про Streamable HTTP спецификация прямо предупреждает: сервер MUST валидировать заголовок Origin, чтобы предотвратить DNS-rebinding-атаки, SHOULD слушать только localhost при локальном запуске и SHOULD реализовать аутентификацию для всех соединений. Это уязвимость уровня транспорта, а не конкретного клиента. Если ты выбрал HTTP-транспорт и пропустил проверку Origin, дырка появляется независимо от того, насколько хорош IDE или 1С-сервер на другом конце.

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

Возьмём конкретную реализацию для 1С, чтобы карта не осталась абстракцией. Сервер mcp-1c (github.com/feenlace/mcp-1c) — одиночный Go-бинарник, который говорит с MCP-клиентом по stdio, но мостит к отдельно опубликованному HTTP-сервису 1С:Предприятия (через Apache или IIS). Для этого HTTP-сервиса он поддерживает опциональную Basic-аутентификацию через --user/--password (или переменные MCP_1C_USER/MCP_1C_PASSWORD). Отдельные --db-user/--db-password нужны только для разового шага --install, который встраивает конфигурационное расширение. То есть у связки два разных набора учётных данных с разной областью действия, и путать их нельзя.

Минимальная поверхность прав тут читаемая. Инструмент execute_query в mcp-1c явно ограничивает запросы только SELECT/ВЫБРАТЬ, а для проверки синтаксиса без выполнения есть отдельный validate_query. Никакие операции записи через обычное использование инструментов не выставлены. Значит минимально достаточное полномочие этой связки: доступ только на чтение метаданных и запросов к базе 1С. Это хороший пример того, как выглядит «минимальные права» на практике: не «доступ к 1С», а «read-only-запросы к конкретной базе через промежуточный HTTP-сервис».

Конфиг stdio-клиента для такой связки выглядит компактно, и в нём сразу видно, где именно живут права:

Даже такую связку я не назову «подтверждённой» до проверки на твоей базе. Спецификация и README описывают контракт, но статус присваивается только после проверяемого подключения с этими минимальными правами и понятной границей отказа. До проверки она честно называется адаптируемой: контракт известен, применимость к твоему контуру пока не подтверждена.

Теперь возьмём соседние системы с тем же словом MCP и посмотрим, совпадают ли у них модели прав. Не совпадают, и это главный тезис.

Второй сервер для 1С показывает разрыв внутри одного домена. Infostart MCP использует транспорт SSE или HTTP (а не связку stdio + HTTP-сервис, как mcp-1c), требует Docker-аутентификации против приватного реестра (docker.f-pix.ru) и сетевого доступа к векторной базе Qdrant и сервису эмбеддингов для RAG-поиска по метаданным. Он явно заявляет, что 1С:EDT не поддерживается. Два «1С MCP-сервера» с одинаковым доменным ярлыком имеют невзаимозаменяемые требования к подключению. Если ты выбрал один и решил, что настройка второго будет такой же, ты ошибся ещё до первой команды.

Игровой движок добавляет третью модель согласия. Официальный MCP-сервер Unity (пакет Unity AI Assistant) подключается по stdio к локальному relay-бинарнику, который общается с редактором Unity через IPC (именованный канал или Unix-сокет). Он различает «AI Gateway connections» (авто-одобрены, без участия пользователя) и «direct connections» (требуют явного согласия через диалог в Project Settings). Это двухуровневая модель согласия, не имеющая отношения ни к SELECT-ограничению 1С, ни к какому-либо OAuth-потоку. Важна оговорка из источников: проверен именно бундл Unity, community-альтернативы вроде mcp-unity существуют с другими транспортами и правами и здесь в глубину не проверялись. Ни один другой игровой MCP-сервер, кроме Unity, в этом наборе фактов не подтверждён.

Клиенты-редакторы кода образуют ещё один слой, и путать клиент с системой нельзя. Cursor документирует три метода подключения MCP: stdio (локально, один пользователь), SSE и Streamable HTTP (удалённо, много пользователей), с разной аутентификацией на метод: ручные учётные данные для локального stdio против OAuth для удалённых HTTP/SSE. По умолчанию Cursor требует одобрения аргументов MCP-инструмента на каждый вызов, если сервер или инструмент не внесён в корпоративный MCP Allowlist. Более того, собственные рекомендации Cursor по безопасности прямо велят проверять источник любого MCP-сервера, смотреть, к каким данным и API он получит доступ, и использовать ключи с минимальными правами до установки. Это явное заявление крупного вендора-клиента: доверие и область сервера проверяются по каждому серверу, а не выводятся из бренда MCP.

Claude Code показывает, что даже одобрение не переносится между серверами. Его система прав многоуровневая по типу инструмента: read-only-инструменты (чтение файлов, grep) внутри рабочей директории не требуют подтверждения, Bash требует подтверждения кроме встроенного read-only-набора команд, а модификация файлов подтверждается всегда. Правила allow/deny/ask заданы по каждому MCP-серверу и инструменту через шаблон имени mcp____. Разрешение, выданное инструментам одного MCP-сервера, не распространяется на другой сервер или клиент. Это ровно то свойство, которое ломает наивную идею, что один раз настроил, и дальше работает везде.

Пользователи приходят к этой проблеме через поиск, и формулировки запросов сами по себе хорошая регрессионная выборка: они показывают, как одно намерение «подключить ИИ» размазано по несовместимым системам. Собери такие запросы в один фикстур, и разрыв между брендом и контрактом станет наглядным.

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

Отдельно стоит коммерческий запрос вайбкодинг на заказ: тот, кто берёт такую работу, продаёт именно проверку связки, а не пересадку одного конфига в чужой контур. Если исполнитель обещает «MCP работает везде», это первый признак, что матрицу он не собирал.

Ни один из этих запросов сам по себе не является фактом о вендоре или продукте. Это формулировки намерения, и ценность фикстура в том, что он превращает расплывчатое «подключить ИИ» в конкретный вопрос: какой протокол, какой клиент, какое минимальное право и подтверждена ли точка подключения.

Классификация принадлежит методу статьи, а не цитате из спецификации, и это разделение я обозначаю честно. Внешние факты: транспорты, авторизация и конкретные детали mcp-1c, Infostart, Unity, Cursor и Claude Code. Присвоение статуса «подтверждённая», «адаптируемая» или «непроверенная», напротив, мой собственный вывод по правилу ниже, и он не расширяется за пределы контракта и прав.

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

Отсюда порядок действий для каждой строки матрицы:

Принятая цена такого подхода честная: широкий rollout замедляется, пока по каждой связке не подтверждены контракт и минимальные права. Спорный размен в том, что тщательная матрица тормозит развёртывание, зато не даёт объявить ложную совместимость. Я выбираю замедление, потому что цена ошибки в учётной базе несопоставима с ценой лишнего часа на проверку.

Модельный маршрут за MCP-клиентом при этом остаётся отдельным слоем от транспорта и прав: точечно проверить provod.ai как один совместимый маршрут можно независимо от статуса самой связки, и это не заменяет пять шагов выше. Технически смена модели сводится к замене ключа и base_url на эндпойнт, совместимый с OpenAI и Anthropic SDK:

Клиент, агент, IDE или бот с OpenAI- или Anthropic-совместимым эндпойнтом продолжает работать без переписывания кода. Баланс в этом случае один и рублёвый: оплата картой РФ, через СБП или по счёту, без VPN и зарубежных карт, а цены моделей идут без наценки provod.ai. Но это подтверждает только один модельный маршрут внутри конкретной связки, а не универсальную совместимость MCP: статус самой связки всё равно присваивается по пяти шагам выше.

Карта связок не подтверждает универсальную совместимость MCP и не заменяет конфигурацию конкретной IDE, 1С или игрового приложения. Это инструмент отбора, а не готовая настройка: подтверждённый статус описывает контракт и права, а не автоматизацию внедрения, инфраструктуру или интеграционную работу, которую всё равно выполняет архитектор.

Ещё одна честная граница— датировка. Совместимость клиентов и их разрешения нужно перепроверять: сведения в этой статье актуальны на 2026-07-18, а страница авторизации MCP черновая, и один из результатов поиска ссылался на release candidate новой ревизии авторизации от 2026-07-28. Точные номера SEP и формулировки MUST/SHOULD могут сдвинуться вскоре после этой даты. Цитируй спецификацию как текущий draft, а не как замороженный финальный стандарт.

И список серверов 1С не исчерпывающий. Экосистема фрагментирована: кроме mcp-1c и Infostart MCP в поиске встречаются 1c_mcp, 1c-mcp-toolkit и другие, но здесь они не проверены. Единого канонического «1С MCP» не существует, и официального одобренного 1С списка в этом наборе фактов нет.

Достаточно ли надписи «поддерживает MCP», чтобы подключать сервер? Нет. Она не сообщает транспорт (stdio или Streamable HTTP), модель авторизации (локальные креды против OAuth 2.1) и область прав. Проверяй эти три вещи отдельно.

Можно ли перенести одобрение с одного MCP-сервера на другой? Нет. В Claude Code правила allow/deny/ask заданы по каждому серверу и инструменту через mcp____, а Cursor по умолчанию требует подтверждения на каждый вызов вне Allowlist. Доверие не переносится.

Все ли игровые связки работают как Unity? Нет. В проверенном наборе подтверждён только официальный MCP-сервер Unity с двухуровневым согласием. Community-серверы для других движков и игр не проверены и относятся к непроверенным.

Какое минимальное право у mcp-1c? Read-only: инструмент execute_query ограничен SELECT/ВЫБРАТЬ, есть отдельный validate_query для проверки синтаксиса без выполнения, операции записи через обычные инструменты не выставлены.

Два «1С MCP-сервера» взаимозаменяемы? Нет: mcp-1c использует связку stdio и HTTP-сервис 1С, тогда как Infostart MCP работает через SSE или HTTP, использует Docker-реестр и Qdrant и не поддерживает 1С:EDT. Требования к подключению не совпадают.

Собери матрицу по своим связкам, а модель за клиентом проверь на provod.ai: один API, совместимый с OpenAI и Anthropic SDK, рублёвый баланс без VPN и зарубежных карт (оплата картой РФ, через СБП или по счёту) и цены моделей без наценки provod.ai. Начни с одной связки, доведи её до статуса «подтверждённая», и только потом расширяй.

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

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Сравнивайте качество и стоимость без скрытой надбавки агрегатора: цены идут 1:1 с официальными тарифами провайдеров, поэтому выбор определяется задачей, а не лишней комиссией provod.ai.

Выберите модель для своего сценария: форма регистрации · цены на модели · защита данных по 152-ФЗ · главная provod.ai