perfonext-render-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| load_render_profileA | Load a React DevTools Profiler JSON export. This is the entry point for the manual profiling path: open React DevTools in the browser → Profiler tab → Record → interact → Stop → Export JSON → share the file path here. Returns a profileId for use with get_render_summary, get_slow_components, get_rerender_causes, and the other analysis tools. |
| compare_rendersA | Diff two loaded render profiles and rank the biggest regressions, improvements, additions, and removals. |
| get_render_summaryA | Summarize the loaded Next.js render profile, including top components by render cost and detected render issues (rerender storms, commit spikes). |
| get_hot_commitsA | Rank the most expensive commits in a loaded render profile and show the top components inside each spike. |
| get_slow_componentsA | Return the slowest components in a loaded Next.js render profile, ranked by total actual render time. |
| get_rerender_causesA | Highlight components with repeated rerenders and explain likely causes using heuristics derived from the exported profile. |
| begin_render_analysisA | Entry point for render profiling. Choose an approach: live — react-scan/lite streams events in real time; exact rerender causes, source locations, changeDescription. manual — no install needed; user exports a JSON from the React DevTools Profiler tab and shares the file path. Ask the user which approach they prefer before calling this tool. |
| run_render_captureA | Called after instrumentation is wired up (steps 1–3 of begin_render_analysis). Ask the user how they want to generate renders before calling this tool: manual-interaction — start the dev server and the user clicks through the app. test-suite — run an existing automated test suite against the running app. |
| stop_render_captureA | Stop a live render-capture session, finalize the buffered events into a render profile, and return a profileId you can use with get_render_summary, get_slow_components, get_rerender_causes, and compare_renders. |
| get_captured_rendersA | Optional diagnostic: peek at the live progress of a render-capture session without stopping it. Returns commit count, components seen, whether actualDuration is populating, and an unknownEvents count (non-zero = instrumentation may not be wired correctly). Only call this if something seems wrong — it is not a required step before stop_render_capture. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools are clearly separated by role: capture lifecycle (begin/run/stop/diagnostic), manual loading, and distinct analysis outputs. The main ambiguity is that both begin_render_analysis and load_render_profile are described as entry points for the manual path, and get_render_summary/get_hot_commits both mention commit spikes, though descriptions are specific enough to disambiguate.
All tool names follow a predictable snake_case verb_noun pattern. Analysis tools use get_ or compare_, capture lifecycle tools use begin/run/stop, and the manual path uses load_, so an agent can infer the role of each tool from its name.
Ten tools is well-scoped for a render-profiling server: there are enough tools to cover both manual and live capture workflows plus analysis, but none feel redundant or purely decorative. Each tool earns its place in a focused pipeline.
The core profiling workflows are well covered: manual JSON loading and live capture both lead to analysis tools, and compare_renders adds regression diffing. The only minor gaps are profile-management conveniences like listing loaded profiles or deleting them, and there is no deep single-commit flamegraph drill-down beyond get_hot_commits.