For the complete documentation index, see llms.txt. This page is also available as Markdown.

Проблемы подключения

Большинство проблем подключения связаны с сетевой конфигурацией Docker. Контейнер работает в изолированной сети и не имеет прямого доступа к localhost хост-машины.

localhost не работает внутри контейнера

Симптом

MCP-сервер не может подключиться к Neo4j, LM Studio или другим сервисам по адресу localhost.

Причина

localhost внутри контейнера указывает на сам контейнер, а не на хост-машину. Сервисы на хосте недоступны по этому адресу.

Решение

Используйте специальный адрес host.docker.internal:

# Неправильно
OPENAI_API_BASE=http://localhost:1234/v1
NEO4J_URI=bolt://localhost:7687

# Правильно
OPENAI_API_BASE=http://host.docker.internal:1234/v1
NEO4J_URI=bolt://host.docker.internal:7687

Если сервис (например, Neo4j) тоже запущен в Docker, используйте имя сервиса из docker-compose:

Cursor не видит MCP-сервер

Проверка 1: Контейнер запущен

Проверка 2: Порт доступен

Проверка 3: Файл mcp.json

Проверка 4: JSON валиден

Решение

  1. Перезапустите Cursor (закройте все окна)

  2. Проверьте правильность URL в mcp.json

  3. Убедитесь, что контейнер запущен и порт доступен

Ошибка "Connection refused"

Симптом

Причины

  1. Контейнер не запущен

  2. Контейнер всё ещё инициализируется

  3. Порт неправильный

Решение

Порт уже занят

Симптом

Найти процесс

Использовать другой порт

Обновите mcp.json:

Windows Firewall блокирует

Проверка

Добавление правила

MCP работает, но ИИ не использует инструменты

Причина 1: Нет Cursor Rules

Добавьте правила, указывающие ИИ использовать MCP:

Причина 2: Неявный запрос

Попробуйте явно указать:

  • "Проверь синтаксис этого кода через MCP"

  • "Найди в справке метод Запрос.Выполнить"

Причина 3: Сервер не подключён

Проверьте список подключённых серверов в Cursor.

Timeout при запросах

Симптом

Запросы к MCP-серверу зависают или возвращают timeout.

Причины

  1. Сервер перегружен (идёт индексация)

  2. Недостаточно ресурсов

  3. Проблемы с embedding моделью

Решение

Сервер «отваливается» после простоя: 404 Session not found

Симптом

Сервер долго не использовался (от 15–30 минут) или клиент держит одну сессию много часов, и следующий вызов падает с HTTP 404: Session not found или, у 1CCodeChecker, session_expired. Контейнер при этом здоров, /health отвечает 200, а сервер в клиенте остаётся недоступным до ручного переподключения.

Причина

Сервер закрыл сессию MCP по простою или по максимальному времени жизни, либо контейнер перезапускался. Это штатное поведение: по спецификации MCP клиент в ответ на 404 должен сам начать новую сессию. Некоторые клиенты этого пока не делают.

Решение

  1. Переподключите сервер в клиенте — этого достаточно, контейнер перезапускать не нужно.

  2. Для IDE-плагинов и долгих агентных прогонов увеличьте простой, например до 8 часов:

Значения по умолчанию и имена переменных всех серверов — в разделе Сессии MCP и ответ 404.

Включение SSE транспорта

Симптом

Некоторые клиенты требуют SSE (Server-Sent Events) вместо стандартного HTTP транспорта.

Решение

Добавьте переменную окружения USESSE=true. Для Graph Metadata Search используйте MCP_USE_SSE=true:

SSE обычно нужен только для legacy-клиентов. Cursor работает со стандартным HTTP транспортом.

Скрипт полной диагностики

Last updated