Когда я готовила материал для цикла про Next.js, то неожиданно для себя узнала, что в нём есть встроенный MCP, который dev-сервер поднимает сам по умолчанию.
Начиная с 16-й версии next dev отдаёт MCP-эндпоинт по адресу /_next/mcp, настраивается это поведение флагом experimental.mcpServer. То есть прямо сейчас у любого запущенного на 16-й версии npm run dev этот эндпоинт открыт.
Внутри обычная middleware ловит всё, что начинается с /_next/mcp, и передаёт запрос в McpServer. Он живёт ровно там же, где HMR, так что в проде его не существует.
Тулов сейчас девять: get_project_metadata, get_routes, get_errors, get_page_metadata, get_logs, get_server_action_by_id, get_request_insights (требует experimental.requestInsights), плюс get_compilation_issues и compile_route — только для Turbopack.
Интересное устройство у get_errors. MCP-клиент дёргает тул → dev-сервер генерит request id и шлёт HMR-сообщение в открытые вкладки → браузер отдаёт состояние своего error overlay → ответ возвращается по тому же каналу → сервер накладывает source maps и складывает с глобальными ошибками инстанса. Поэтому для его полноценной работы требуется открытая вкладка в браузере. Тул get_page_metadata работает так же.
Благодаря такому MCP агент может сам спрашивать у живого приложения на Next.js, какая ошибка сейчас на странице, какие есть роуты и т.д. Я ещё не успела воспользоваться им в полной мере, но для задач вроде обновления сборки или большого рефакторинга, где меняется рендеринг, думаю, это может быть очень полезно.
Стоит помнить, что это неаутентифицированный эндпоинт, который отдаёт структуру проекта, пути к файлам и логи. Поэтому если вы по каким-то причинам пробрасываете dev-сервер наружу, то наружу уезжает и он.
Начиная с 16-й версии next dev отдаёт MCP-эндпоинт по адресу /_next/mcp, настраивается это поведение флагом experimental.mcpServer. То есть прямо сейчас у любого запущенного на 16-й версии npm run dev этот эндпоинт открыт.
Внутри обычная middleware ловит всё, что начинается с /_next/mcp, и передаёт запрос в McpServer. Он живёт ровно там же, где HMR, так что в проде его не существует.
Тулов сейчас девять: get_project_metadata, get_routes, get_errors, get_page_metadata, get_logs, get_server_action_by_id, get_request_insights (требует experimental.requestInsights), плюс get_compilation_issues и compile_route — только для Turbopack.
Интересное устройство у get_errors. MCP-клиент дёргает тул → dev-сервер генерит request id и шлёт HMR-сообщение в открытые вкладки → браузер отдаёт состояние своего error overlay → ответ возвращается по тому же каналу → сервер накладывает source maps и складывает с глобальными ошибками инстанса. Поэтому для его полноценной работы требуется открытая вкладка в браузере. Тул get_page_metadata работает так же.
Благодаря такому MCP агент может сам спрашивать у живого приложения на Next.js, какая ошибка сейчас на странице, какие есть роуты и т.д. Я ещё не успела воспользоваться им в полной мере, но для задач вроде обновления сборки или большого рефакторинга, где меняется рендеринг, думаю, это может быть очень полезно.
Стоит помнить, что это неаутентифицированный эндпоинт, который отдаёт структуру проекта, пути к файлам и логи. Поэтому если вы по каким-то причинам пробрасываете dev-сервер наружу, то наружу уезжает и он.