MCP-сервер не работает? Диагностика по симптому, а не по клиенту

Самая частая причина жалобы «ассистент не видит мои данные» — вовсе не сломанный сервер. Это клиент, который ни разу не перезапустили после правки конфигурации. Большинство MCP-клиентов читают конфигурацию при старте и больше никогда, поэтому файл, отредактированный при открытом приложении, — это файл, который приложение не читало. Закройте его полностью — на macOS закрытие окна оставляет процесс работать — и откройте заново. В Claude Code вместо перезапуска терминала выполните /mcp.

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

Сначала найдите экран состояния

Прежде чем что-либо менять, посмотрите, что клиент уже знает. У каждого клиента есть ровно одно место, которое отвечает на вопрос «этот сервер подключился?», и попытки угадать это по окну чата — как раз тот способ потратить час на проблему, которую тот экран называет за секунду.

Клиент Куда смотреть Как выглядит здоровый сервер
Claude Code claude mcp list или панель /mcp ✔ Connected
Claude Desktop значок плюса в поле ввода → Connectors сервер в списке вместе со своими инструментами
Cursor панель Output (Cmd+Shift+U) → MCP Logs инициализация без ошибок подключения
VS Code MCP: List Servers в Command Palette сервер стартует, журнал Show Output чистый
Zed Settings → AI → MCP Servers зелёная точка, подсказка Server is active

Самый информативный здесь — Claude Code. claude mcp list печатает рядом с каждым сервером состояние здоровья — ✔ Connected, ! Needs authentication, ✘ Failed to connect, ⏸ Pending approval — и дописывает в ту же строку подробности сбоя; claude mcp get <name> показывает то же самое в строке Issue:, включая текст ошибки, который вернул сам сервер.

Сервера вообще нет в списке

Если экран состояния не показывает ваш сервер, значит клиент не читает написанную вами запись. Почти всё сводится к трём причинам.

Файл не разбирается как корректный JSON. Одна лишняя запятая или одна незакрытая скобка — и клиент игнорирует весь файл целиком, а не только испорченную запись, обычно ничего об этом не сообщая. Прежде чем подозревать что-то ещё, вставьте файл в любой валидатор JSON.

Вы отредактировали не тот файл, который читает клиент. Почти у каждого клиента есть и личная конфигурация, и конфигурация уровня проекта, и правка не той из них даёт ровно этот симптом. Cursor читает ~/.cursor/mcp.json глобально и .cursor/mcp.json внутри проекта; VS Code читает .vscode/mcp.json в рабочей папке и mcp.json профиля пользователя, который открывается командой MCP: Open User Configuration. У Claude Code три области — local и user в ~/.claude.json, project в файле .mcp.json в корне репозитория, — и если имя определено более чем в одной, local побеждает project, а project побеждает user. Запись целиком берётся из победившей области; поля не смешиваются.

Имя ключа не подходит этому клиенту. У VS Code ключ верхнего уровня — servers, у Zed — context_servers, у всех остальных mcpServers. Вставленный в VS Code блок mcpServers не вызывает ошибки, о которой редактор сообщит, — это просто ключ, который он не читает. Разбор по клиентам — в статье где лежит конфигурация MCP.

Один случай выглядит как пропавший сервер, но им не является: в Claude Code сервер уровня проекта стоит в состоянии ⏸ Pending approval, пока вы не запустите claude интерактивно в этой папке и не подтвердите его, а подтверждения, закоммиченные в репозиторий, не действуют, пока вы не доверитесь этой рабочей папке.

Вчера работало, сегодня перестало

Когда в конфигурации ничего не менялось, а сервер перестал подключаться, в конфигурации обычно всё ещё лежит абсолютный путь к программе, которой там больше нет. Обновление приложения в другую папку, переименование или перенос из Applications ломают путь, тогда как JSON по-прежнему выглядит правильным, и ничто в сообщении клиента на этот переезд не указывает. Проверьте значение command на соответствие реальности прежде всего остального:

ls -l "/absolute/path/from/your/config"

Тот же класс сбоя бьёт по серверам, которые запускаются через менеджер версий. Если command — это node, npx, python или uv, а ваша среда исполнения приходит из nvm, pyenv или asdf, путь существует в вашем терминале и не существует для клиента, потому что клиент не запускает входную оболочку. Замените голое имя абсолютным путём — его подскажет which node — или укажите в command сам исполняемый файл.

Сервер подключается, но не отдаёт инструментов

Зелёное состояние при пустом списке инструментов означает, что рукопожатие прошло, а tools/list не вернул ничего полезного. К этому приводят две вещи.

Первая — сервер, который действительно сообщает о пустом наборе инструментов; убедиться в этом можно вне клиента, через MCP Inspector — эталонный интерфейс для тестирования, который подключается к серверу по stdio или Streamable HTTP напрямую и перечисляет то, что тот публикует. Если Inspector видит инструменты, а ваш клиент нет, дело в конфигурации клиента.

Вторая — потолок инструментов. VS Code ограничивает один запрос в чате 128 включёнными инструментами и отказывает в запросе, когда общее число выходит за предел, а на загруженной машине это происходит быстрее, чем можно ожидать; выключить лишние серверы, чтобы вернуться под лимит, можно кнопкой Configure Tools в представлении Chat. Cursor позволяет отключать отдельные серверы в панели Customize на боковой панели, и отключённый сервер не загружается и не появляется в чате — это стоит проверить первым делом, потому что переключатель, который кто-то щёлкнул месяц назад, выглядит точно так же, как сервер, который не смог запуститься.

На любой запрос приходит «ничего не найдено»

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

Чтение работает, любое изменение падает

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

«Is not valid JSON» и соединения, которые сразу закрываются

Это ошибка сервера, а не ваша, но узнавать её стоит, потому что сообщение сбивает с толку. По stdio протокол требует, чтобы в стандартный вывод не попадало ничего, кроме сообщений JSON-RPC, поэтому сервер, печатающий в stdout баннер с версией, строку о запуске или цветной журнал, портит поток, и клиент падает с ошибкой разбора, цитирующей первые символы напечатанного, — Unexpected token 'S', "Starting s"... is not valid JSON. Исправлять это автору сервера: строки журнала идут в stderr, который хост и так перехватывает.

Вторая ловушка при запуске — окружение. Сервер на stdio наследует лишь ограниченный, зависящий от платформы набор переменных окружения, а не ваш профиль оболочки, и его рабочий каталог может быть не определён — на macOS фактически /. Передавайте то, что нужно серверу, через ключ env в его записи конфигурации и держите все пути абсолютными.

В каком порядке проверять

  1. Полностью перезапустите клиент. Примерно половина обращений заканчивается здесь.
  2. Откройте экран состояния своего клиента и прочитайте, что он говорит.
  3. Проверьте JSON на корректность и убедитесь, что правили тот файл, который читает клиент.
  4. Убедитесь, что путь в command существует и записан абсолютным.
  5. Проверьте, что сервер не выключен, а потолок инструментов не заполнен.
  6. Проверьте данные — верная учётная запись, верное устройство, синхронизация прошла.
  7. И только затем читайте журналы.

Пройти сверху вниз стоит минуту. Начать с седьмого пункта — способ превратить пятисекундную проблему в целый вечер.

Как это выглядит в Speak-Y

Speak-Y поставляет свой MCP-сервер внутри приложения для macOS, поэтому несколько описанных выше сбоев с ним просто невозможны: нет пакета npm, который надо ставить, нет среды исполнения, которую надо искать через nvm, и нет токена, который может протухнуть. Возможен только устаревший путь, и приложение чинит его само. При запуске оно проверяет конфигурации Claude Code, Claude Desktop и Cursor и переписывает значение command там, где оно указывает на старое расположение приложения, — но только для записей, которые действительно принадлежат ему, опознанных по исполняемому файлу приложения и аргументу --mcp, так что чужой сервер со случайно совпавшим именем остаётся нетронутым. Если нужно сделать это руками, в разделе Настройки → Интеграции рядом с каждым найденным клиентом есть кнопка Переустановить; после этого перезапустите клиент или выполните /mcp в Claude Code.

Разделение на чтение и изменение — второй симптом, который стоит уметь распознавать. Поиск по записям и чтение расшифровок, саммари и задач работают прямо по библиотеке на этой машине и не требуют, чтобы что-то было запущено. Инструменты, которые наводят порядок, — теги, названия, имена спикеров, повторная расшифровка, публикация в командный канал, — идут через запущенное приложение, поэтому при закрытом Speak-Y они отказывают, а поиск продолжает работать. Эта асимметрия сама по себе диагностика: если чтение работает, а изменение нет, запустите приложение, а не правьте конфигурацию. Добавленный в аргументы сервера --read-only полностью убирает меняющие инструменты из поля зрения клиента — это задуманное поведение, а не поломка. Пустые ответы от здорового сервера обычно означают, что запись всё ещё на другом устройстве: сервер читает этот диск и не ходит за остальным.

Если вы не чините, а настраиваете, полезнее этой страницы будут пошаговые инструкции по клиентам: Claude Desktop и Claude Code по шагам и VS Code, Zed и Devin Desktop — для редакторов, форма конфигурации у которых отличается от всех остальных.

FAQ

Почему ассистент не видит MCP-сервер, который я только что добавил?

Большинство клиентов читают конфигурацию MCP только при запуске, поэтому файл, записанный при работающем клиенте, ещё не прочитан. Полностью выйдите из приложения и откройте его заново — на macOS закрыть окно недостаточно, — а в Claude Code вместо перезапуска терминала выполните /mcp.

Как проверить, что MCP-сервер действительно подключился?

У каждого клиента есть одно место, которое отвечает на этот вопрос. Claude Code: claude mcp list, где рядом с каждым сервером печатается ✔ Connected, ! Needs authentication или ✘ Failed to connect. Claude Desktop: значок плюса в поле ввода, затем Connectors. VS Code: команда MCP: List Servers из Command Palette. Cursor: панель Output с выбранным MCP Logs. Zed: Settings → AI → MCP Servers, где зелёная точка подписана Server is active.

Где лежат журналы MCP в Claude Desktop?

В ~/Library/Logs/Claude на macOS и в %APPDATA%\Claude\logs на Windows. Читать их вживую удобно командой tail -n 20 -F ~/Library/Logs/Claude/mcp*.log. В файле mcp.log лежат общие события подключения, а в mcp-server-NAME.log — то, что конкретный сервер написал в stderr.

Сервер работает в терминале, но падает в клиенте. Почему?

Клиент запускает процесс сам, а не через вашу входную оболочку. Он не наследует ваш полный PATH — только ограниченный, зависящий от платформы набор переменных окружения, — а рабочий каталог может быть не определён. Указывайте абсолютный путь в command, абсолютные пути в аргументах и передавайте нужные переменные явно через ключ env.

После обновления приложения ассистент перестал видеть мои записи. Что сломалось?

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