Как найти сбой между клиентом MCP и базой 1С

Если клиент MCP не видит 1С, сначала выясните, запускается ли сервер и каким транспортом он связан с клиентом. Затем проверьте адрес базы, учётную запись и права в самой 1С. Универсального порта, токена и файла настроек для всех реализаций нет; ниже — порядок проверки, который помогает найти конкретный разрыв.

1. Уточните, какой именно сервер подключаете

Первое, что я выясняю, — название и версия конкретной реализации. MCP задаёт правила обмена клиента с сервером, но сам по себе не устанавливает службу mcp-server, не создаёт файл mcp_config.json и не назначает общий api_token. Эти названия могут встречаться в отдельных проектах, но переносить их на любой сервер нельзя. В качестве примера есть открытое расширение 1С MCP_Сервер.cfe. Это конкретная реализация, и её настройки не становятся настройками других серверов. В условном сценарии с ООО «Фрегат-Строй» я бы сперва попросил ссылку на репозиторий или инструкцию установленного решения. Иначе мы чиним неизвестную систему по чужой инструкции. Так обычно и появляются уверенные советы про службы, которых на машине нет.

Зафиксируйте четыре вещи: что установлено в 1С, где запускается сервер, какой клиент к нему подключается и какую схему связи выбрали. Некоторые реализации используют расширение внутри 1С, другие — отдельный процесс или прокси; наличие расширения не доказывает, что внешний процесс запущен. В проекте 1c_mcp автор описывает расширение конфигурации и Python-прокси — это конкретная архитектура, а не обязательное устройство каждого MCP-подключения. Поэтому я сверяю инструкцию с фактически установленным компонентом, а не с похожим названием из поисковой выдачи. Для работ с платформой и размещением базы можно привлечь специалистов по 1С и серверной инфраструктуре, но сначала нужно установить, какая именно часть цепочки не отвечает.

Запишите в короткую карточку название проекта и ссылку на источник, версию по документации сборки, место запуска и пользователя, от имени которого работает процесс. Если в документации предусмотрено расширение .cfe, отметьте, загружено ли оно в нужную конфигурацию. Если проект предусматривает отдельный прокси, проверьте именно его процесс и журнал. Версия языка, имя службы и способ перезапуска имеют смысл только в контексте этой реализации. Проверка статуса службы уместна только тогда, когда у вас действительно есть служба с таким именем и соответствующая система управления процессами. На Windows, в контейнере или при запуске через клиент способ проверки будет другим.

Не начинайте с переустановки 1С и не открывайте входящие порты наугад. Сначала посмотрите, есть ли в инструкции шаг «запустить сервер» или клиент стартует его сам как дочерний процесс. Это разные модели. В первом случае проверяют запущенный процесс и его журнал; во втором — команду запуска, путь к исполняемому файлу и вывод ошибки, который получает клиент. У клиента также должна быть включена поддержка MCP и запись о сервере, если такую настройку требует его производитель. Одного установленного компонента в базе недостаточно: клиент должен знать, как связаться с сервером, а сервер — к каким данным обращаться. В базе знаний отдельно подтверждены эти шаги: сервер подключают к источнику данных, затем добавляют к совместимому клиенту.

• Назовите точную реализацию MCP-сервера.
• Найдите её инструкцию и проверьте версию.
• Установите, запускается ли сервер отдельно или клиентом.
• Запишите фактическую команду запуска и место журнала.

2. Проверьте транспорт и адрес сервера

После идентификации проекта проверьте способ обмена между клиентом и сервером. В спецификации MCP описаны stdio и Streamable HTTP. При stdio клиент запускает сервер как дочерний процесс и обменивается сообщениями через стандартный ввод и вывод. При HTTP сервер работает как отдельный процесс, а клиент обращается к заданной конечной точке. Поэтому проверка доступности конкретного TCP-порта не является универсальной проверкой MCP: при stdio сетевого порта вообще может не быть, а у HTTP-сервера адрес и порт задаёт конкретная реализация. Порт 8080 или 8443 нельзя объявлять значением по умолчанию без документации к установленному серверу.

Для HTTP-сценария возьмите адрес целиком из инструкции: схема (http или https), имя узла, порт, если он указан, и путь конечной точки. Спецификация приводит /mcp как пример пути, но это не гарантирует, что ваш сервер слушает именно его. Сверьте URL с конфигурацией запущенного процесса и настройкой клиента посимвольно. Проверьте DNS-имя с компьютера, где работает клиент, а не только с сервера 1С: одинаковый адрес может разрешаться в разные сети. Дальше проверьте доступность узла и порта средствами вашей операционной системы и сетевого оборудования. Если симптом выглядит как общий отказ соединения, пригодится отдельный разбор ошибки подключения к серверу 1С. Проверка HTTP-адреса может получить ответ об ошибочном методе или авторизации; это подтверждает маршрут до веб-службы, но ещё не успешный обмен MCP.

Если сервер использует stdio, вместо проверки firewall выясните, запускает ли клиент правильную команду в нужном рабочем каталоге и доступен ли исполняемый файл пользователю клиента. Ошибка при старте может попасть в журнал клиента или stderr дочернего процесса. Сервер не должен печатать отладочные сообщения в stdout, если туда передаются сообщения протокола: такой вывод ломает обмен. Не угадывайте команду по чужому конфигу; сравните поле запуска, аргументы и переменные окружения с инструкцией именно вашей сборки. Если клиент показывает «сервер отключён», это может означать как отказ процесса при старте, так и ошибку HTTP-подключения — сами слова интерфейса не указывают причину.

Сетевой экран меняйте только после того, как установили, что используется HTTP-транспорт и какой адрес действительно слушает сервер. Если соединение локальное, проверьте привязку к интерфейсу: служба, слушающая только localhost, не будет доступна с другого узла. Если доступ нужен по сети, ограничьте источники соединений и включите предусмотренную сервером авторизацию. Не добавляйте правило межсетевого экрана как универсальное лечение — порт может быть другим, а транспорт вообще может не использовать TCP. Спецификация рекомендует для локального сервера привязку к 127.0.0.1 и предупреждает о проверке Origin и аутентификации HTTP-соединений. Открытый всем адрес ради одной проверки — плохой обмен безопасности на удобство.

• Для `stdio` проверяйте запуск процесса и stdout/stderr.
• Для HTTP сверьте полный URL и путь endpoint.
• Проверяйте DNS и маршрут с узла клиента.
• Правьте сетевой экран только для подтверждённого порта.

3. Сверьте адрес базы и вход в 1С

Когда клиент уже связывается с MCP-сервером, переходите к источнику данных. Проверьте, что сервер смотрит на нужную информационную базу, а не на тестовую, пустую или соседнюю. В одном из сценариев подключения к 1С через Битрикс24 в параметрах указываются адрес сервера 1С, логин и пароль пользователя 1С. Это конкретная схема той интеграции, а не общее требование MCP; у другого проекта поля и способ авторизации могут отличаться. Ищите адрес, пользователя и пароль в конфигурации того компонента, который действительно соединяется с 1С. Не выдумывайте универсальные db_user и db_password: таких общих полей протокол не устанавливает.

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

Подключите отдельного пользователя с минимальными необходимыми разрешениями, если прикладное решение и интеграция позволяют это сделать. Но не создавайте вслепую роль Read: права в 1С задаются ролями конкретной конфигурации, а набор доступных операций и объектов зависит от прикладного решения. Официальная документация платформы описывает основные и интерактивные права и поясняет, что структура ролей определяется прикладным решением. Если система не принимает пользователя, отдельно проверьте идентификацию пользователя 1С. Для чтения данных может требоваться не только общее разрешение на просмотр: права могут ограничивать отдельные объекты, поля и записи. Проверьте доступ именно к тем данным или инструментам, которые сервер должен читать. Учётная запись администратора не должна быть первым вариантом проверки — она маскирует недостающие разрешения и расширяет последствия ошибки.

В условном примере ООО «Фрегат-Строй» я бы сравнил адрес, логин и результат обычного входа пользователя с тем, что настроено у MCP-компонента, а затем проверил его права в используемой конфигурации 1С. Я не стану приписывать этому примеру конкретный пароль, порт или успешный срок исправления: без журналов это была бы выдумка. Если штатный вход в базу не проходит, сначала исправьте его и повторите проверку без посредника. Если вход проходит, но клиент не видит доступные данные, ищите следующий разрыв — разрешения пользователя, доступность нужной функции в MCP-сервере или ошибку преобразования ответа. Результат каждой проверки фиксируйте отдельно, чтобы не менять одновременно пароль, сеть и роли.

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

4. Разберите авторизацию и права клиента

Не всякое MCP-подключение использует API-токен. В спецификации авторизация на транспортном уровне описана как необязательная возможность; для HTTP-подключений предусмотрен отдельный механизм, а для stdio рекомендуются другие способы передачи учётных данных. Конкретный сервер может применять OAuth, токен, переменные окружения, собственную авторизацию или не использовать дополнительный слой сверх аутентификации к источнику данных. Поэтому фраза «создайте API-ключ в панели» годится только для сервиса, который действительно выдаёт такой ключ. В нашей базе есть пример сервиса, где токен создаётся в аккаунте поставщика; это факт о том сервисе, а не правило MCP. Проверьте раздел авторизации своего проекта и не храните секреты в открытом общем конфигурационном файле.

Для клиентской проверки подтвердите, что сервер добавлен в настройки совместимого приложения и выбран правильный тип транспорта. Формат записи зависит от клиента; поле настройки, которое встречается в одном приложении, не является обязательным полем спецификации MCP. Убедитесь, что формат JSON корректен, имя команды и аргументы существуют, а переменные окружения переданы тому процессу, который запускает сервер. Если применяется OAuth, проверьте, завершён ли вход в браузере и выданы ли нужные разрешения. Если применяется токен, проверьте источник, актуальность и область доступа. Не вставляйте секреты в сообщения, снимки экрана или историю команд; передавайте их способом, предусмотренным приложением.

Сравните три уровня прав: клиенту разрешено подключить сервер; MCP-серверу разрешено выполнять нужный инструмент; пользователю 1С разрешено читать соответствующие данные. Один успешный уровень не доказывает остальные. Сервер может быть доступен и авторизован, но не предоставлять запрошенную функцию. Функция может существовать, но пользователь 1С не иметь доступа к выбранному регистру. Клиент может успешно обменяться служебными сообщениями, но не показывать результат из-за фильтра или формата ответа. Запросите у сервера список доступных возможностей способом, который поддерживает ваш клиент, и выполните самый простой безопасный запрос из инструкции. Сопоставьте его имя с документацией реализации, не отправляя сразу операцию, которая меняет данные.

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

• Определите, какой механизм авторизации поддерживает сервер.
• Проверьте, что клиент использует этот же механизм.
• Разделите права клиента, MCP-инструмента и пользователя 1С.
• Повторите безопасный штатный запрос после изменения настроек.

5. Сверьте версии, журналы и результат запроса

Проверка версий нужна после того, как известны названия компонентов. Уточните, какие версии клиента, MCP-сервера, расширения 1С и платформы 1С поддерживает разработчик конкретной сборки. Не подставляйте «версию протокола 2.0» или «драйвер последней версии» из старого черновика: протокол согласует поддерживаемые версии в ходе обмена, а требования зависят от реализации. Обновлять всё подряд — сомнительный первый шаг. Сначала запишите текущие версии и воспроизведите ошибку, затем сравните их с таблицей совместимости или заметками к выпуску проекта. Если несовместимость подтверждена, обновите один компонент в согласованное окно и повторите тот же запрос.

Читайте журналы в порядке прохождения запроса: сначала клиент, затем MCP-сервер или прокси, затем компонент подключения к 1С и журнал самой базы, если он доступен. Сверьте время ошибки, тип транспорта и текст ответа. Не публикуйте в статье или обращении пароли, токены, персональные данные и полные строки подключения. Сообщение connection refused обычно указывает на отказ установить TCP-соединение, но не устанавливает, какой порт следовало открыть и почему процесс не слушает. 401 у HTTP-сервиса указывает на проблему авторизации запроса на этом уровне, но не говорит, что пользователь 1С неверен во всех остальных механизмах интеграции. Смотрите контекст запроса и журнал принимающей стороны.

Если имя узла не разрешается, проверьте DNS из окружения процесса, которому нужно подключиться. Утилита проверки DNS уместна, если речь действительно об имени хоста; такая проверка не диагностирует права 1С или ошибки протокола. Не подменяйте DNS вручную как постоянный обход невыясненной проблемы: сначала подтвердите ожидаемый адрес и выясните, почему ответ отличается. Для Windows используйте доступные штатные средства разрешения имён. Если клиент и сервер работают в разных подсетях, отдельно проверьте маршрут, фильтрацию и локальные правила. Меняйте одну настройку за раз и сохраняйте исходный результат — иначе будет неясно, что именно исправило или ухудшило связь.

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

• Сверьте версии с документацией конкретного проекта.
• Сопоставьте журналы клиента, сервера и 1С по времени.
• Проверьте DNS только если используется имя узла.
• Подтвердите результат безопасным запросом к ожидаемой базе.

Частые вопросы