# MCP-сервер: невалидный JSON даёт 500 вместо ошибки JSON-RPC; в документации MCP не описана авторизация

> Что сделано
- Исправлен ответ MCP-сервера на испорченный запрос: обрыв JSON, пустое тело и не-JSON теперь дают ошибку протокола -32700 «Parse error» с обычным кодом 200, а не 500 internal_error. В журнал как внутренний сбой такие запросы больше не попадают.
- Верный JSON, который не является сообщением JSON-RPC (42, [], строка, пустая пачка сообщений), даёт -32600 «Invalid Request». Негодное сообщение внутри пачки больше не теряется молча: на него приходит отдельный ответ с ошибкой, остальные сообщения пачки выполняются.
- Заодно починен общий случай: испорченный JSON на любом другом адресе API теперь отвечает 400, а не 500.
- Раздел документации «API: MCP-сервер» дополнен: откуда берётся токен системного пользователя и как он отзывается, зачем заголовок Authorization нужен на каждый запрос, как скоупы влияют на вызовы и почему tools/list всё равно отдаёт весь список, проверка доступа на каждый объект, ограничение на создание страниц только под выданным родителем, ответы 401 без токена и с неверным токеном, 405 на GET, коды ошибок протокола и пример подключения для Claude Code и Claude Desktop.
- Добавлены тесты на новое поведение и гвардия сборки; код закоммичен версией 5.44.121 и уедет на dev общей сборкой, когда закончатся задачи в очереди.

Что не получилось
- Всё по требованию сделано.

На что обратить внимание
- tools/list намеренно оставлен независимым от скоупов токена: список инструментов собирается из описания API, а нехватка прав видна при вызове. В требовании это допускалось как альтернатива — поведение описано в документации.
- Сообщения ошибок протокола оставлены в привычном для JSON-RPC виде: «Parse error: …» и «Invalid Request: …» с русским пояснением, чтобы клиенты узнавали стандартный текст.