Perfonext Build MCP

io.github.souvikdu由 GitHub 帳號 souvikdu 發布v0.6.2更新於 Oct 24, 2026

MCP server for Next.js build stats, chunk attribution, and bundle optimization advice.

已驗證STDIO僅桌面開發者工具資料與分析

概覽

AI 產生的概覽

本機 MCP 伺服器,讀取 Next.js 的 .next 建置產物,讓助理取得路由體積排名、共用 chunk 與重複依賴分析以及打包最佳化建議。

可以做什麼
  • 載入 Next.js 建置目錄,並把快照保存在記憶體中供後續查詢
  • 依體積排名最大的路由,以及影響最多路由的共用 chunk
  • 比對基準與目前建置,說明體積成長來源,並在檔名帶內容雜湊時仍能配對 chunk
  • 追蹤某個模組或 npm 套件為何被打包,並找出跨 chunk 重複的套件(需選用的 webpack stats 檔)
  • 提供蒐集 webpack stats 的步驟,並把各項發現彙整成依嚴重度排序、附證據的最佳化建議
適用情境
適合處理 Next.js 效能問題:找出哪些路由送出最多 JavaScript、診斷兩次建置之間的體積成長,或決定先精簡哪個依賴或匯入。它是給已執行 next build 的開發者使用的唯讀分析工具。
執行需求
以 stdio 在本機執行,通常透過 npm 套件 @perfonext/build-mcp 以 npx 啟動,因此 PATH 中需有 Node.js 與 npm(macOS 上使用 nvm 的圖形介面用戶端可能需要 npx 的絕對路徑)。需要既有的 .next 建置目錄;匯入層級歸因還需 .next/stats.json 中的 webpack stats 檔,一般 next build 不會產生,Turbopack 建置也無法產生。未宣告帳號、金鑰或環境變數。
安裝前請注意
它只讀取本機建置產物並在記憶體中保存快照,不涉及憑證、付費或遠端服務。選用的 stats 流程會要求加入 webpack-stats-plugin 與 cross-env 並修改 next.config,套用前請先檢視這些變更。沒有 stats 檔時歸因工具會降級處理而非報錯。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Perfonext Build MCP,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。

其他 MCP 客戶端

參照 儲存庫 中的啟動說明。

README

perfonext-build-mcp

Analyze Next.js build artifacts to find heavy routes, shared chunks, and bundle growth.

[npm] [npm downloads] [license] [website]

perfonext-build-mcp is a Model Context Protocol (MCP) server that gives GitHub Copilot, Claude Desktop, Claude Code, and other MCP clients structured bundle analysis for Next.js performance work. It loads .next build artifacts and turns them into route-size rankings, shared-chunk and duplication findings, and severity-ranked fix suggestions — evidence agents can reason over instead of inspecting raw .next manifests.

Quick Start

perfonext-build-mcp is a standard MCP stdio server, so it works with any MCP-compatible client (GitHub Copilot in VS Code, Claude Desktop, Claude Code, Cursor, and others). Run it directly with npx:

bash
npx -y @perfonext/build-mcp

Or install globally:

bash
npm install -g @perfonext/build-mcp

The executable command remains perfonext-build-mcp after installation.

VS Code

Add the server to .vscode/mcp.json (the workspace MCP configuration file):

json
{  "servers": {    "perfonext-build": {      "type": "stdio",      "command": "npx",      "args": ["-y", "@perfonext/build-mcp"]    }  }}

Reload the VS Code window and run MCP: List Servers to start it, or accept the trust prompt when it appears.

Claude Desktop

Add the server to claude_desktop_config.json:

json
{  "mcpServers": {    "perfonext-build": {      "command": "npx",      "args": ["-y", "@perfonext/build-mcp"]    }  }}

Restart Claude Desktop to pick up the new server.

Claude Code

Add the server with the CLI:

bash
claude mcp add perfonext-build -- npx -y @perfonext/build-mcp

Or add it directly to .mcp.json:

json
{  "mcpServers": {    "perfonext-build": {      "command": "npx",      "args": ["-y", "@perfonext/build-mcp"]    }  }}

Other MCP clients

Any client that supports stdio MCP servers can launch the same command/args pair: command: npx, args: ["-y", "@perfonext/build-mcp"]. Consult your client's docs for where its MCP server configuration file lives.

For a locally-built checkout, point command/args at node and the repo's dist/index.js instead, in any of the configurations above.

Then ask your assistant: "Load the Next.js build in ./.next and show me the largest routes."

Troubleshooting

spawn npx ENOENT / spawn node ENOENT on macOS with nvm

If the server fails to start with spawn npx ENOENT (or spawn node ENOENT), your editor/app was likely launched from the Dock/Finder and cannot see nvm. GUI apps on macOS do not load shell config (.zshrc/.bashrc), so npx/node installed via nvm are not on PATH. This applies to VS Code, Claude Desktop, and any other GUI MCP client on macOS.

Fix it by giving the MCP config an absolute npx path and a PATH that includes the same Node bin directory (dirname $(which npx)):

json
{  "command": "/Users/YOU/.nvm/versions/node/v<version>/bin/npx",  "args": ["-y", "@perfonext/build-mcp"],  "env": {    "PATH": "/Users/YOU/.nvm/versions/node/v<version>/bin:/usr/bin:/bin"  }}

Merge the command/args/env fields above into your client's server entry (e.g. under servers for VS Code or mcpServers for Claude Desktop/Code).

What It Does

  • loads Next.js build artifacts from a .next directory
  • ranks the largest user-facing routes by emitted bundle footprint
  • identifies the heaviest shared chunks that affect multiple routes
  • compares two builds and explains which routes and chunks drove bundle growth, with severity-ranked, evidence-backed fix suggestions
  • matches chunks across builds even though Next.js fingerprints filenames with content hashes
  • traces why a given module or npm package is bundled (import chain entry → module) when an optional webpack stats file is collected
  • finds npm packages duplicated across chunks and explains what dominates shared chunks
  • aggregates all of the above into severity-ranked, evidence-backed optimization suggestions tied to concrete Next.js actions
  • keeps loaded build snapshots in memory so an MCP client can inspect them without re-reading the same build

Tools

ToolDescription
load_build_statsParse a Next.js .next directory and load the build snapshot into memory
get_largest_routesRank the heaviest user-facing routes by total emitted chunk bytes
get_shared_chunksRank shared chunks by size and show which routes depend on them
compare_buildsCompare a baseline and current build snapshot to show which routes and chunks grew or shrank
explain_growthSeverity-rank which routes and chunks drove bundle growth between two builds, with evidence-backed fix suggestions
how_to_collect_statsReturn the recipe (manual) or an action plan (automatic) to generate .next/stats.json
load_webpack_statsParse .next/stats.json and link it to a loaded build; required before trace_import
trace_importExplain why a module or npm package is bundled by walking its import chain to the entry
find_duplicatesRank npm packages whose code is emitted into more than one chunk, by wasted bytes
explain_shared_chunksShow which packages and app code dominate the shared chunks loaded by many routes
suggest_optimizationsAggregate route, chunk, and webpack-stats evidence into severity-ranked, evidence-backed fix suggestions

The output stays machine-readable and includes raw byte counts so your MCP client can explain regressions, prioritise fixes, and suggest concrete dependency or import-level follow-up.

Every suggest_optimizations finding is sized in emittedBytes — actual on-disk chunk bytes — so suggestions of different kinds rank on one scale. Unminified webpack module sizes appear only where they are named as such (moduleSizeBytes, shareOfChunkModuleBytes).

Because Next.js content-hashes emitted filenames (framework-<hash>.js, and CSS files named purely by hash), compare_builds and explain_growth match chunks across builds by a hash-normalized identity. This prevents a rehashed-but-unchanged chunk from being misreported as removed-and-recreated, while still flagging genuinely new chunks.

Inputs

The core tools read build artifacts developers already have after running next build:

  • .next/build-manifest.json
  • .next/prerender-manifest.json when present
  • .next/app-build-manifest.json when present
  • .next/app-path-routes-manifest.json when present — maps App Router manifest keys (/gallery/page) to the real paths (/gallery) the prerender manifest is keyed by, so route type, isPrerendered, and prerenderBlockedReason are read from the build rather than guessed from the path
  • optional captured next build output text to derive build duration

Import-level attribution (trace_import, find_duplicates, explain_shared_chunks) and the stats-enriched suggestions from suggest_optimizations additionally need a webpack module-stats file at .next/stats.json. A stock next build does not emit one; how_to_collect_stats returns the recipe to generate it. The manifest tools above never read it, so they work with or without it.

Deep bundle attribution (optional)

The manifest tools work with zero setup. To answer "why is this package bundled?", collect a webpack stats file first:

  1. Call how_to_collect_stats({ method: 'manual' | 'automatic' }) and apply the returned steps — it adds webpack-stats-plugin and cross-env, gates a next.config hook behind ANALYZE=true && !isServer, and rebuilds with cross-env ANALYZE=true next build --webpack. Turbopack builds will not produce .next/stats.json.
  2. Call load_build_stats({ buildDir }) to get a buildId.
  3. Call load_webpack_stats({ buildId }) to parse the generated .next/stats.json.
  4. Call trace_import({ buildId, moduleName }) to see the import chain that pulls a module in.
  5. Call find_duplicates({ buildId }) to find packages bundled into more than one chunk, and explain_shared_chunks({ buildId }) to see what dominates the chunks loaded by many routes.
  6. Call suggest_optimizations({ buildId }) for severity-ranked, evidence-backed recommendations. It works on manifests alone and is enriched with dedupe, shared-chunk, and package-import findings once stats are loaded. Code-split advice is tailored for Next.js framework routes (/404, /500, /_error, /_app, /_document) — these are flagged to be slimmed down by trimming imports rather than split with next/dynamic, which does not apply to them.

If the app builds with Turbopack there is no webpack module graph, so how_to_collect_stats says so and points back to the manifest-only tools. The attribution tools degrade gracefully with a breadcrumb when no stats file is loaded — it is never an error.

Example Prompts

  • "Load the Next.js build in ./.next and show me the largest routes."
  • "Which shared chunks are affecting the most routes in this build?"
  • "Summarize the build footprint and tell me which routes ship the most JavaScript."
  • "Compare my baseline and current .next builds and show me which routes or shared chunks grew the most."
  • "Explain what grew between my baseline and current .next builds and what I should fix first."
  • "Set up webpack stats collection so I can see why a package is bundled."
  • "Why is axios in my bundle? Trace its import chain."
  • "Which npm packages are duplicated across chunks and how many bytes are wasted?"
  • "What's dominating my shared chunks?"
  • "Suggest the highest-impact bundle optimizations for this build."

Related Perfonext Tools

Development

bash
npm installnpm run buildnpm test

Sample fixtures for local validation live under tests/fixtures/.

License

MIT

來源:README.md,提交 9a42b51

工具

0
SourceWeft 尚未在沙箱中啟動過該軟體包,因此其工具未知。

版本歷史

1
  1. v0.6.2最新Sep 16, 2026

評分

已滿足適用檢查項的 50%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通25 分

    請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。

  • 已宣告認證方式10 分

    請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。

  • 已列出工具15 分

    請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。

  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分