你以为 AI 写前端只能靠发布后才知道兼容不对？MDN 今天把这件事接进了 AI 的工作流

MDN MCP Server 是什么

MCP（Model Context Protocol）是一个开放标准，让 AI 工具连接外部数据源。MDN MCP Server 则把 MDN 的文档和浏览器兼容性数据，通过这个协议提供给 AI 编码助手。

简单说：你在 Claude Code 里问一个 Web API 的用法，AI 会实时查 MDN，而不是调记忆。

支持的工具

类别	工具
编辑器	VS Code、Zed、Cursor
Agent CLI	Claude Code、Codex CLI、Antigravity CLI
聊天应用	Claude Desktop

接入方式（以 Claude Code 为例）

claude mcp add --transport http mdn https://mcp.mdn.mozilla.net/

一行命令，接入完成。之后你在 Claude Code 里问任何 Web API 相关问题，AI 都会实时拉取 MDN 的最新文档。

---

实测对比：没有 MCP vs 有 MCP，差距有多大

MDN 团队用 Claude Code Opus 4.7 做了对比测试，同样问四个 Firefox 151 新特性，对比有 MCP 和没有 MCP 的回答质量。

Web Serial API

没有 MCP：

「Firefox 不支持且不在路线图上。」（错误）

有 MCP：

准确列出支持情况，并注明 Firefox 151 于 2026 年 5 月正式支持。

根本原因： Claude Code 的训练数据里没有 Firefox 151 的信息，而它没有意识到自己不知道。

shadowrootslotassignment 属性

没有 MCP：

「Chrome 120 和 Safari 18.3 支持。」（混淆了 Element.attachShadow() 的 slotAssignment 选项）

有 MCP：

「Firefox 151 是第一个支持此属性的浏览器。」（准确）

light-dark() 图片用法

没有 MCP：

「支持不太统一。」（模糊，无具体信息）

有 MCP：

提供完整的浏览器支持表格，列出 Firefox 150 和带 flag 的 Chrome 为支持版本，并附代码示例。

结论

在浏览器兼容性这个维度，有 MCP 的回答质量全面优于没有 MCP——因为 AI 调用的不再是记忆，而是实时文档。

---

怎么工作的

MDN MCP Server 部署在 https://mcp.mdn.mozilla.net/，支持两种接入方式：

远程接入（推荐，一行命令）：

claude mcp add --transport http mdn https://mcp.mdn.mozilla.net/

本地自托管：

git clone https://github.com/mdn/mcp.git
cd mcp
npm install
npm start
# 然后把 localhost:3002 注册到你的 MCP 客户端

项目托管在 GitHub mozilla/mdn 仓库，采用 Mozilla Public License 2.0。

---

局限性

MDN 也明确说了几件事：

1. 目前是实验阶段，URL 在正式版前可能变更，不适合直接用于生产环境
2. 会收集查询数据（用于改进服务），有隐私顾虑可以用 X-Moz-1st-Party-Data-Opt-Out: 1 header 退出
3. 不是所有问题都有显著改善——简单用法问题两者差距不大，差距主要在浏览器兼容性和新特性上

---

下一步

如果你是 AI 辅助前端开发的深度用户，装一个试试：

# Claude Code 用户
claude mcp add --transport http mdn https://mcp.mdn.mozilla.net/

然后问它几个你最近踩过坑的 API 兼容问题，对比一下有 MCP 和没有 MCP 的答案。

如果你用的是其他 MCP 兼容工具（Zed、Cursor、VS Code），流程也类似——查对应工具的 MCP 配置文档，把上面的远程地址加进去就行。

---

今天 MDN 把 AI 写代码时查到的 API 兼容性这件事接上了实时数据源。 知识截止日期的问题不是 AI 本身的问题，是信息来源的问题——MDN 今天把这个问题从根上原生化了。