最近前端仓库里多了一类文件：.mcp.json、AGENTS.md、版本对得上的 llms.txt。它们不是给浏览器看的，是给写代码的 Agent 看的。
Next.js 16 起，dev server 默认挂着 /_next/mcp。Vercel 的 next-devtools-mcp 负责发现本机多个 Next 实例，把运行时工具转给 Cursor / Claude / Codex 一类客户端。文档里列的能力很直白：拉当前 build/runtime/type error、读开发日志路径、扫路由表、查页面元数据。Agent 不用再瞎猜「这个项目现在卡在哪」。
这跟「把 README 塞进上下文」不是一回事。README 是静态说明书；MCP 工具读的是这一刻的 dev server 状态。路由刚加、类型刚红、console 刚炸，Agent 能直接问运行时，而不是翻你三天前的笔记。
工具面长什么样
典型链路是：
- 你照常
next dev - 客户端连上
next-devtools-mcp（或等价 connector） - Agent 调
get_errors/get_routes/get_page_metadata这类工具 - 再决定改哪个文件、跑哪条命令
官方文档还提到：多个端口上的 Next 实例可以被发现并转发。这对 monorepo 挺有用——web 和 docs 各开一个 dev，Agent 不用你手动指端口。
社区和框架侧也在同一方向挤：MUI、Storybook、Playwright 都在给 Agent 备 MCP 或 skills。前端工具链的「用户」从人扩到了人 + 会调工具的模型。你不爱用 Agent 也无所谓，但依赖作者开始默认「有人会用机器读我的错误输出」。
图：俯拍工作台——路由清单、便签与手机上的界面草稿，和宽屏桌面封面不是同一构图。
工程上真正要守的边界
把 live 错误交给外部进程，等于多开了一扇窗。本地 lone wolf 无所谓；共享机、CI 旁路、给同事演示的临时隧道，就要想清楚：
- 只绑 loopback。MCP 端点不该无脑暴露到公网或公司 Wi-Fi。
- 工具白名单。Agent 需要
get_errors，不需要随手rm -rf。权限模型和你给 CI token 的心态一样：最小集。 - 别把 secret 打进可被工具读的日志。Agent 会读 log path；你
console.log(process.env)的坏习惯现在多了一位读者。 - 版本对齐。Next 强调 versioned docs for agents，就是为了避免模型按 14 的心智改 16 的项目。仓库里放对版本的 docs 入口，比口头说「我们用 App Router」稳。
我自己的用法是：MCP 当诊断通道，不当无审批写入通道。先让它读错误和路由，改文件仍走你熟悉的 diff 流程。等团队对 harness 有审计，再谈自动 apply。
和「框架内导航优化」是两条线
上周很多人聊 Instant Navigations、Turbopack chunk。那些优化的是用户点链接之后的体感。MCP 优化的是你改代码之前 Agent 能不能看见真相。
两条线会碰头。比如 Agent 修完 hydration 报错，下一步用真实 soft navigation 的 web-vitals 验证——Next 也在让 useReportWebVitals 覆盖 SPA soft navigations。诊断快了，验证也得跟得上，否则只是把瞎改的速度加快了。
落地可以很克制
最小可行：
# 项目根 .mcp.json（示意）
{
"mcpServers": {
"next-devtools": {
"command": "npx",
"args": ["-y", "next-devtools-mcp"]
}
}
}
然后保证 next dev 在跑，客户端能发现 /_next/mcp。先只开读类工具，观察一周 Agent 提案的质量，再决定要不要加更重的能力（浏览器自动化、直接打 Server Action 等）。
若你根本不用 Agent，至少做两件小事：错误信息写清楚；关键路径在仓库里有一份机器可读索引。未来某个同事的 Agent 会谢你，未来的你排查线上复现时也会谢你。
小结
前端 DX 正在多出一层「给 Agent 的运行时 API」。Next 的 MCP 端点不是噱头，它把 dev server 从「人眼看终端」变成「工具可查询的状态源」。
好处是少一轮「把报错贴进聊天」的复制。代价是你必须像对待任何调试接口一样对待它：绑定地址、权限、日志卫生、版本文档。
先让 Agent 看清错误，再谈让它改代码。顺序反了，只会更快地制造需要 MCP 才能读懂的新错误。
