Mozilla 為 AI 開發工具打造 MDN MCP 伺服器，網頁相容性資料即時上線
MDN Blog · 2026-06-15
Mozilla 於 2026 年 6 月 15 日正式發表 MDN MCP Server，這是一項以 Model Context Protocol（MCP）為基礎的實驗性服務，讓 AI 程式助理與 IDE 外掛能夠直接查詢 MDN 的文件庫與瀏覽器相容性資料。目標是解決 LLM 訓練資料具有截止日期的根本問題，避免開發者收到過時的 Web API 建議。
背景：LLM 的知識截止日期問題
大型語言模型在訓練完成後便無法主動取得新發布的 Web 平台資訊。以 CSS @view-transition at-rule 為例，若 LLM 的訓練資料未涵蓋該特性，就可能給出無效或不完整的使用範例。瀏覽器相容性更是高度動態的資訊——光是今年 Firefox 151 就新增了 Web Serial API 支援——這類變動難以被訓練資料即時反映。MDN MCP Server 正是為了填補這道落差而生。
核心功能
MDN MCP Server 透過遠端 HTTP 傳輸提供三大工具：MDN 全文搜尋、Web 平台文件內容、以及 BCD（Browser Compatibility Data）查詢。伺服器架設於 https://mcp.mdn.mozilla.net/，無須本地安裝即可直接使用。對於有隱私顧慮的團隊，MDN 也提供了在本地端（預設 port 3002）自行部署的選項；原始碼已以 Mozilla Public License 2.0 授權開放於 github.com/mdn/mcp。
安裝與整合方式
以 Claude Code 為例，只需一行指令即可完成設定：
claude mcp add --transport http mdn https://mcp.mdn.mozilla.net/此外，MDN MCP Server 也支援 VS Code、Zed、Cursor 等主流編輯器，以及 Codex CLI 和 Antigravity CLI 等 Agent 工具。各平台的設定方式可分別參閱 VS Code 官方文件、Zed 文件與 Cursor 文件。
實測效果比較
MDN 團隊在文章中展示了啟用 MCP 前後的回答差異。啟用後，LLM 能夠正確回報 Firefox 151 已支援 Web Serial API，而未啟用 MCP 的版本則給出「Firefox 不支援」的錯誤答案。在回應速度方面，整合 MCP 後的速度約為原先的兩倍，原因在於 LLM 不再需要對不確定的相容性資訊進行大量推理。
| 比較項目 | 無 MCP | 有 MDN MCP |
|---|---|---|
| 瀏覽器相容性準確度 | 依賴訓練資料，可能過時 | 即時查詢 BCD，反映最新狀況 |
| 新特性覆蓋率 | 受訓練截止日期限制 | 可查詢最新發布的 Web 平台功能 |
| 回應速度（實測） | 基準值 | 約快 2 倍 |
實驗性質與隱私注意事項
MDN 強調此服務目前仍屬實驗階段，隨時可能下線，不建議作為生產環境的強依賴。在資料蒐集方面，服務會記錄查詢內容，但不會與使用者身份綁定；若需停用分析追蹤，可在請求中加入 X-Moz-1st-Party-Data-Opt-Out: 1 標頭。問題回報與功能建議可至 GitHub Issues 或 MDN Discord 社群提交。
原始來源：MDN Blog — Introducing the MDN MCP server、github.com/mdn/mcp、MDN MCP 官方頁面
2026 年 WebAssembly 執行環境效能總評：Wasmer 奪冠，wide_arithmetic 成決勝關鍵
00f.net · 2026-06-23
資安研究員 Frank DENIS 於 2026 年 6 月 23 日發布了年度 WebAssembly 執行環境效能測試報告，橫跨 2024 至 2026 年的追蹤數據，涵蓋 9 款主流 Wasm 執行環境。今年的最大亮點是 wide_arithmetic 指令集擴充帶來的顯著提升，以及 Wasmer 首次在綜合評比中拿下最佳成績。
背景與測試方法
測試基準採用 libsodium 密碼學函式庫編譯而成的 WebAssembly 模組，以加密運算的幾何平均值作為對原生 x86-64 執行速度的相對指標（slowdown ratio）。硬體平台為 AMD Ryzen AI 9 HX 470，鎖定 2 GHz 並停用 CPU boost 以確保數據一致性。測試分為四種建置配置：
- 純 WebAssembly 基線（無額外 CPU 特性）
- 啟用
lime1特性的建置 - 啟用
simd128的建置 - 啟用
wide_arithmetic（目前 Phase 3 提案）的建置
2026 年排名結果
Wasmer 以 1.33 倍原生速度的成績拿下第一，且必須在啟用 wide_arithmetic 的條件下才能達到此數值。以下為各執行環境在最佳支援建置下的排名：
| 排名 | 執行環境 | 最佳相對速度（倍於原生） | 關鍵配置 |
|---|---|---|---|
| 1 | Wasmer | 1.33× | wide_arithmetic |
| 2 | WAVM | 1.41× | — |
| 3 | WAMR AOT | 1.42× | — |
| 4 | Wasmtime | 1.46× | wide_arithmetic |
| 5 | WasmEdge | 1.64× | — |
wide_arithmetic 提案的實際影響
wide_arithmetic 是一個目前處於 Phase 3 的 WebAssembly 提案，主要新增了用於 128 位元及更寬整數運算的原生指令，使密碼學、大數運算等場景無需借助 SIMD 繞路即可高效執行。根據本次測試，支援該提案的執行環境（Wasmer、Wasmtime）其 slowdown ratio 相較未啟用時下降約 40%，顯示這項提案在計算密集型工作負載上的潛力相當可觀。
各執行環境三年趨勢觀察
從 2024 到 2026 年的縱向資料中，Wasmtime 展現最穩定的年年進步幅度，Bytecode Alliance 的持續投入可見一斑；Bun 則在 2025 至 2026 年間出現大幅躍升，反映了 JavaScriptCore 底層 Wasm JIT 的積極優化。相比之下，Wazero 整體數值穩定但進展趨緩，作為純 Go 實作的執行環境，在高度密碼學工作負載下仍面臨先天限制。
- Wasmtime：三年連續改善，最具持續性
- Bun：2025→2026 年間出現大幅提升
- Wazero：純 Go 實作，數值平穩但成長停滯
- Node.js：基於 V8，表現中規中矩
測試侷限性說明
作者明確指出，此測試僅代表密碼學計算場景，不能直接類推至通用 Wasm 工作負載。libsodium 的計算特性偏向整數密集，對 SIMD 與 wide_arithmetic 較為敏感；圖形渲染、字串處理或 I/O 密集型場景的執行環境排名可能大相逕庭。此外，WAVM 雖然排名第二，但其開發活躍度相對較低，在選擇執行環境時仍需考量社群支援與長期維護能力。
原始來源：00f.net — Performance of WebAssembly runtimes in 2026、github.com/bytecodealliance/wasmtime、WebAssembly wide-arithmetic 提案