
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.
概览
本地 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 构建也无法生成。未声明账号、密钥或环境变量。
安装
在 SourceWeft 中
- 打开 控制台中的 Perfonext Build MCP,将其添加到工作区。
- 为需要使用其工具的对话启用该服务。
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:
Or install globally:
The executable command remains perfonext-build-mcp after installation.
VS Code
Add the server to .vscode/mcp.json (the workspace MCP configuration file):
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:
Restart Claude Desktop to pick up the new server.
Claude Code
Add the server with the CLI:
Or add it directly to .mcp.json:
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)):
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
.nextdirectory - 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
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.jsonwhen present.next/app-build-manifest.jsonwhen present.next/app-path-routes-manifest.jsonwhen present — maps App Router manifest keys (/gallery/page) to the real paths (/gallery) the prerender manifest is keyed by, so routetype,isPrerendered, andprerenderBlockedReasonare read from the build rather than guessed from the path- optional captured
next buildoutput 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:
- Call
how_to_collect_stats({ method: 'manual' | 'automatic' })and apply the returned steps — it addswebpack-stats-pluginandcross-env, gates anext.confighook behindANALYZE=true && !isServer, and rebuilds withcross-env ANALYZE=true next build --webpack. Turbopack builds will not produce.next/stats.json. - Call
load_build_stats({ buildDir })to get abuildId. - Call
load_webpack_stats({ buildId })to parse the generated.next/stats.json. - Call
trace_import({ buildId, moduleName })to see the import chain that pulls a module in. - Call
find_duplicates({ buildId })to find packages bundled into more than one chunk, andexplain_shared_chunks({ buildId })to see what dominates the chunks loaded by many routes. - 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 withnext/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
./.nextand 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
.nextbuilds and show me which routes or shared chunks grew the most." - "Explain what grew between my baseline and current
.nextbuilds and what I should fix first." - "Set up webpack stats collection so I can see why a package is bundled."
- "Why is
axiosin 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
- perfonext-profiler-mcp — CPU profiling (V8/Chrome) for Next.js servers
- perfonext-render-mcp — React render analysis for Next.js apps
Development
Sample fixtures for local validation live under tests/fixtures/.
License
MIT
来源:README.md,提交 9a42b51
工具
0版本历史
1- v0.6.2最新Sep 16, 2026
评分
已满足适用检查项的 50%
该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。
- 近 30 天内可连通25 分
请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。
- 已声明认证方式10 分
请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。
- 已列出工具15 分
请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。
- 描述必需15 分
- 图标10 分
- 文档15 分
- 许可证10 分