Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@v8-cpu-profile-decoder-mcp show me the top 5 CPU-consuming functions from /app/profiles/profile.cpuprofile"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that decodes V8 CPU profiles into token-efficient bottleneck summaries for AI agents.
Your Node.js app is slow. You ran --cpu-prof. Now you have a 20MB .cpuprofile file — and your AI agent is completely blind to it.
V8 CPU profiles are massive. A typical .cpuprofile from a production Node.js app is 5–50MB of raw JSON — millions of lines mapping memory addresses, tick counts, and microsecond execution sequences. It looks like this:
{
"nodes": [
{ "id": 1482, "callFrame": { "functionName": "processRequest", "url": "file:///app/dist/server.js", "lineNumber": 847 }, "hitCount": 3241, "children": [1483, 1490] },
...
],
"samples": [1482, 1483, 1482, 1490, 1482, ...],
"timeDeltas": [120, 98, 115, 102, ...]
}An AI agent attempting to read this file instantly collapses its context window and fails. Even if it could read it, it can't run the aggregation algorithms needed to compute inclusive/exclusive CPU times across the call tree.
So when you ask your agent:
🙈 "Which function is consuming the most CPU?"
🙈 "What's calling my slow database query?"
🙈 "Which TypeScript file is the bottleneck actually coming from?"
...it's guessing. It has no access to the profiling data.
v8-cpu-profile-decoder-mcp fixes that. It decodes the profile locally and hands the agent a 10-line semantic summary instead of a 50MB file.
Related MCP server: javaperf
extract_hottest_functionsParses the .cpuprofile and returns the top N functions ranked by exclusive CPU time (self time).
Filters out V8 internals and Node.js built-ins — only user code.
{
"profile_path": "/app/profiles/CPU.20260516.cpuprofile",
"top_n": 5,
"min_self_percent": 1.0
}[
{
"rank": 1,
"functionName": "hashPassword",
"url": "file:///app/dist/auth/crypto.js",
"lineNumber": 42,
"selfTimeMs": 1842.5,
"totalTimeMs": 1842.5,
"selfPercent": 61.32,
"totalPercent": 61.32,
"hitCount": 3241
},
{
"rank": 2,
"functionName": "parseJsonBody",
"url": "file:///app/dist/middleware/body.js",
"lineNumber": 18,
"selfTimeMs": 412.1,
"totalTimeMs": 412.1,
"selfPercent": 13.71,
"totalPercent": 13.71,
"hitCount": 724
}
]analyze_call_tree_pathFinds all callers of a specific function and shows how often each one invoked it. Accepts partial, case-insensitive function name matching.
{
"profile_path": "/app/profiles/CPU.20260516.cpuprofile",
"function_name": "hashPassword",
"top_callers": 3
}{
"targetFunction": "hashPassword",
"matchedNodes": 2,
"totalSelfTimeMs": 1842.5,
"totalPercent": 61.32,
"callers": [
{
"functionName": "loginHandler",
"url": "file:///app/dist/routes/auth.js",
"lineNumber": 94,
"callCount": 2180,
"selfTimeMs": 240.1
},
{
"functionName": "validateSession",
"url": "file:///app/dist/middleware/auth.js",
"lineNumber": 31,
"callCount": 1061,
"selfTimeMs": 116.8
}
]
}correlate_source_codeMaps compiled JS bottlenecks back to their original TypeScript source locations using .js.map files.
Falls back gracefully to compiled JS locations if no source map is found.
{
"profile_path": "/app/profiles/CPU.20260516.cpuprofile",
"top_n": 5
}{
"resolved": [
{
"rank": 1,
"generatedUrl": "file:///app/dist/auth/crypto.js",
"generatedLine": 42,
"source": {
"originalFile": "src/auth/crypto.ts",
"originalLine": 38,
"originalColumn": 2,
"originalFunction": "hashPassword"
},
"selfTimeMs": 1842.5,
"selfPercent": 61.32
}
],
"sourcemapErrors": []
}analyze_gc_pressureReports garbage collection overhead as a percentage of profiling duration, broken down by GC type. Flags when GC exceeds a configurable threshold and provides a targeted recommendation.
{
"profile_path": "/app/profiles/CPU.cpuprofile",
"threshold_percent": 10
}{
"gc_ticks": 184,
"total_ticks": 1240,
"gc_percentage": 14.84,
"gc_type_breakdown": {
"scavenger": 122,
"mark_sweep": 0,
"mark_compact": 0,
"incremental": 62,
"generic": 0
},
"exceeds_threshold": true,
"threshold_percent": 10,
"verdict": "GC consumed 14.84% of CPU — exceeds the 10% threshold. Dominated by Scavenger (short-lived object pressure). Consider object pooling, reusing buffers, or reducing closure captures."
}diff_profilesCompares two .cpuprofile files (before/after an optimization) and returns per-function CPU time deltas,
normalized against each profile's total duration. Frames are matched by call-frame coordinates, not
transient node IDs, so alignment is stable across profiling sessions.
{
"before_profile_path": "/app/profiles/before.cpuprofile",
"after_profile_path": "/app/profiles/after.cpuprofile",
"top_n": 5
}{
"before_duration_ms": 5000,
"after_duration_ms": 4800,
"total_execution_delta_ms": -200,
"total_execution_delta_percent": -4,
"top_improvements": [
{
"function_name": "hashPassword",
"url": "file:///app/dist/auth/crypto.js",
"line_number": 42,
"before_ms": 1842.5,
"after_ms": 620.1,
"absolute_diff_ms": -1222.4,
"relative_diff_percent": -66.34
}
],
"top_regressions": [],
"only_in_before": [],
"only_in_after": []
}analyze_async_bottlenecksDetects event-loop overhead by identifying V8 internal frames representing async machinery —
microtask queue processing, nextTick saturation, and timer/immediate callbacks.
{
"profile_path": "/app/profiles/CPU.cpuprofile",
"threshold_percent": 10
}{
"total_ticks": 1240,
"async_ticks": 186,
"event_loop_overhead_ms": 372,
"event_loop_overhead_percent": 15.0,
"dominant_async_patterns": [
{ "pattern": "promise_chains", "ticks": 142, "percent": 11.45 },
{ "pattern": "nexttick_saturation", "ticks": 44, "percent": 3.55 }
],
"verdict": "Event-loop overhead is 15.0% of CPU — exceeds the 10% threshold. Promise chain overhead is visible in the profile. Consider batching microtasks, using Promise.all() to parallelise I/O, or offloading CPU-bound continuations to worker threads."
}npx v8-cpu-profile-decoder-mcpOr install globally:
npm install -g v8-cpu-profile-decoder-mcp# Single run
node --cpu-prof your-script.js
# With custom output dir
node --cpu-prof --cpu-prof-dir ./profiles your-script.jsOr programmatically via Chrome DevTools → Performance tab → Record.
{
"mcpServers": {
"v8-cpu-profile-decoder-mcp": {
"command": "npx",
"args": ["-y", "v8-cpu-profile-decoder-mcp"]
}
}
}"Here's my CPU profile at
/app/profiles/CPU.cpuprofile— which function is consuming the most CPU?"
"Find what's calling
processRequestin this profile and how often"
"Map the top 10 hottest functions back to their original TypeScript files"
"My Node.js API is slow under load — profile is at
/tmp/CPU.cpuprofile, find the bottleneck"
"Is GC the bottleneck? Check the profile at
/tmp/CPU.cpuprofileand tell me what kind of allocation is causing it"
"Compare these two profiles before and after my optimization — which functions improved and which regressed?"
"Is this app spending too much CPU on async overhead and event-loop machinery?"
playwright-trace-decoder-mcp — decode Playwright traces for CI failure root-cause analysis
playwright-network-chaos-mcp — simulate network failures and latency in browser sessions
flakiness-knowledge-graph-mcp — knowledge graph of flaky test patterns
ast-impact-mapper-mcp — find affected tests from code changes via TypeScript AST
playwright-spatial-layout-mcp — geometric spatial awareness of web layouts
MIT © vola-trebla
Detects event-loop overhead in a V8 CPU profile by identifying V8 internal frames that represent async machinery — microtask queue processing, nextTick saturation, and timer/immediate callbacks. These frames are invisible to most profilers but consume real CPU when promise chains are deep or nextTick is overused. Use to answer: is the bottleneck async orchestration overhead rather than synchronous computation?
| Name | Required | Description | Default |
|---|---|---|---|
| profile_path | Yes | Absolute path to the .cpuprofile file | |
| threshold_percent | No | Async overhead percentage above which a warning is emitted in the verdict (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds valuable context about why these frames are invisible to profilers and when they consume CPU (deep promise chains, nextTick overuse). However, it does not explicitly state that the operation is read-only, describe side effects, or outline the return format. While the analytical wording implies a safe read, the transparency is not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a purpose: the first states the core action, the second provides necessary technical nuance, and the third gives a crisp usage question. It is front-loaded and contains zero filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description is quite complete. It covers detection target, mechanism, and a concrete use-case. The absence of an explicit return description is a minor gap, but the threshold_percent schema's 'verdict' mention and the description's question form partially compensate by implying a resulting answer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: profile_path is described as an absolute path and threshold_percent has a default, range, and behavior note about a verdict warning. The description itself adds no parameter-level detail, so the schema fully carries the meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Detects') and precise resource ('event-loop overhead in a V8 CPU profile by identifying V8 internal frames'), clearly distinguishing it from siblings like extract_hottest_functions or analyze_gc_pressure. It names exact async mechanisms (microtask processing, nextTick saturation, timer/immediate callbacks), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use to answer: is the bottleneck async orchestration overhead rather than synchronous computation?' This tells the agent when to select this tool. However, it does not explicitly state when not to use it or name alternative sibling tools, so it falls short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds all callers of a specific function in a V8 CPU profile and returns how often each caller invoked it. Accepts partial, case-insensitive function name matching. Use to answer: what is calling my slow function and how many times?
| Name | Required | Description | Default |
|---|---|---|---|
| top_callers | No | Number of top callers to return (default: 5) | |
| profile_path | Yes | Absolute path to the .cpuprofile file | |
| function_name | Yes | Function name to search for (partial match, case-insensitive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds value by explaining the matching behavior (partial, case-insensitive) and the return format (caller frequencies), but these are partially redundant with the schema. It does not explicitly state that the tool is read-only or describe behavior for edge cases like no matches, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and contains no filler. Each sentence contributes meaning: what it does, how matching works, and a concrete use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema), the description adequately covers the core purpose, matching behavior, and output relevance. It could be slightly stronger by noting what happens when no callers are found or emphasizing that it is a read-only operation, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already well-documented. The description adds minimal extra meaning beyond the schema, mainly clarifying the purpose of the function_name and the nature of the returned data. This aligns with the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Finds all callers'), the target ('a specific function in a V8 CPU profile'), and the output ('returns how often each caller invoked it'). It distinctly separates this tool from siblings like 'extract_hottest_functions' or 'analyze_gc_pressure' by focusing specifically on caller analysis for a named function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context with 'Use to answer: what is calling my slow function and how many times?', which tells the agent when to invoke it. However, it does not mention when not to use it or compare it to alternatives, though the sibling tool list offers some degree of differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyses a V8 .cpuprofile for garbage collection overhead. Reports total GC time as a percentage of profiling duration, broken down by GC type (Scavenger = short-lived object pressure, Mark-Sweep/Mark-Compact = old-space pressure, Incremental = high allocation rate). Flags when GC exceeds a configurable threshold and provides a targeted recommendation. Use to answer: is GC the bottleneck, and what kind of allocation pattern is causing it?
| Name | Required | Description | Default |
|---|---|---|---|
| profile_path | Yes | Absolute path to the .cpuprofile file | |
| threshold_percent | No | GC percentage above which exceeds_threshold is set to true and a warning is emitted (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It details what the tool computes (percentage, GC-type breakdown), how it classifies pressure (Scavenger vs. Mark-Sweep vs. Incremental), and the threshold-flagging behavior. It does not describe exact return formatting, but the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four tightly packed sentences, front-loaded with the main purpose, then details, then an actionable use-case question. Every sentence contributes useful information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex, and the description covers the analytical output (percentage, breakdown, flag, recommendation) sufficiently given the absence of an output schema. It could be more explicit about the exact return structure, but the behavioral outline and threshold semantics provide enough context for an agent to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds minimal semantic value beyond the schema, only mentioning a 'configurable threshold' without introducing new details about parameter usage or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Analyses') and resource ('V8 .cpuprofile') with a clear scope ('garbage collection overhead'). It distinguishes the tool from siblings like extract_hottest_functions and analyze_call_tree_path by focusing exclusively on GC metrics and bottleneck diagnosis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage question ('is GC the bottleneck...') and explains the type of allocation pattern diagnosis, but it does not explicitly mention when NOT to use this tool or name alternative tools. Still, the context is unambiguous and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Maps the hottest functions in a V8 CPU profile back to their original TypeScript source locations using source map files (.js.map). Falls back to compiled JS locations if no source map is found. Use to answer: which TypeScript file and line is the bottleneck actually coming from?
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | Number of hottest functions to resolve (default: 10) | |
| profile_path | Yes | Absolute path to the .cpuprofile file | |
| sourcemap_dir | No | Override directory to search for .map files (default: same directory as .js file) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It openly states the fallback behavior ('Falls back to compiled JS locations if no source map is found'), which is a significant behavioral trait. It does not explicitly say the tool is read-only or describe failure modes, but the disclosed fallback adds meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and contains no filler. Every phrase earns its place, including the fallback detail and the example question that frames usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is reasonably complete for a tool with well-documented parameters and no output schema. It explains the input, the transformation, and the fallback, and provides an example question. It does not describe what the return value looks like, but given the absence of an output schema and the relatively simple purpose, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal parameter meaning beyond the schema—it mentions source map files (.js.map) and the fallback, which indirectly clarifies `sourcemap_dir`, but it does not elaborate on `profile_path` or `top_n` beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Maps') and clearly names the resource ('hottest functions in a V8 CPU profile' back to 'original TypeScript source locations'). It distinguishes itself from siblings like extract_hottest_functions by emphasizing the source-map correlation step, making its unique purpose obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case ('Use to answer: which TypeScript file and line is the bottleneck actually coming from?'), which tells the agent when to use it. However, it does not explicitly mention when *not* to use it or reference alternatives, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compares two V8 .cpuprofile files (before and after an optimization) and returns per-function CPU time deltas, normalized against each profile's total duration. Frames are matched by call-frame coordinates (functionName + url + line + column), not by transient node IDs, so alignment is stable across profiling sessions. Use to answer: which functions improved or regressed after my change, and by how much?
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | Number of top improvements and regressions to return (default: 5) | |
| after_profile_path | Yes | Absolute path to the optimized .cpuprofile file to compare against the baseline | |
| before_profile_path | Yes | Absolute path to the baseline .cpuprofile file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description discloses key behaviors: matching by call-frame coordinates rather than transient node IDs, and normalization against total duration. This adds meaningful transparency beyond schema fields, though it does not cover error handling or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no fluff. The purpose is front-loaded, and the second sentence provides valuable detail on matching stability and a concrete use case, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 params, no annotations, and no output schema, the description gives the tool's purpose, matching method, normalization, and a concrete question to answer. It lacks a precise structure of the return value, but it is adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all three parameters (100%), including descriptions for before/after paths and top_n. The description reinforces that before is baseline and after is optimized, but does not add extra semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'compares' and clearly states the resource (two V8 .cpuprofile files) and the output (per-function CPU time deltas). It distinguishes from sibling profiling tools by emphasizing before/after optimization comparison and stable frame matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a direct use-case: 'Use to answer: which functions improved or regressed after my change, and by how much?' This gives clear context for when to use the tool, though it does not explicitly mention when not to use it or name alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parses a V8 .cpuprofile file and returns the top N functions ranked by exclusive CPU time (self time). Filters out V8 internals and Node.js built-ins by default, returning only user code. Framework frames (express, next.js, koa, etc.) can be collapsed into a single entry. Recursive calls to the same source location are merged with an instanceCount field. Use this first to identify which functions are consuming the most CPU in a Node.js performance profile.
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | Number of hottest functions to return (default: 10) | |
| profile_path | Yes | Absolute path to the .cpuprofile file | |
| min_self_percent | No | Minimum self time percentage to include a function (default: 0.5%) | |
| collapse_recursion | No | Merge multiple nodes with the same source location (functionName + url + line + column) into one entry. instanceCount shows how many recursive instances were merged (default: true) | |
| collapse_frameworks | No | Collapse all frames from known frameworks (express, next.js, koa, fastify, nestjs, react, vue, nuxt, hapi) into a single "<framework> internals>" entry per framework. Prevents dozens of small framework entries from diluting the top-N list (default: true) | |
| include_node_internals | No | Include V8 internals and Node.js built-ins in results (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of disclosing behavior. It reveals key defaults: filtering out V8 internals/Node.js built-ins, collapsing framework frames, and merging recursive calls with an instanceCount. These details go beyond the parameter schema by explaining the tool's processing behavior, though it does not mention error handling or output structure, preventing a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loads the core purpose in the first sentence. Each subsequent sentence adds relevant behavioral details without unnecessary verbosity. It is concise, well-structured, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, no output schema, no annotations), the description covers the core functionality, usage context, and key behavioral defaults. It explains the return concept (top N by exclusive time) but does not detail the exact fields of the returned objects. However, it is sufficient for an agent to understand the tool's role and initiate a call, so it earns a 4 rather than a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some context (e.g., 'exclusive CPU time (self time)' and 'instanceCount field') but does not significantly enhance the parameter meanings already provided in the schema. The parameter descriptions are already detailed, so the description offers marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Parses a V8 .cpuprofile file') and its primary output ('returns the top N functions ranked by exclusive CPU time'), using specific verbs and resource. It distinguishes itself from sibling tools by focusing on hottest functions via self-time, which is unique among the listed alternatives. The phrase 'Use this first' further clarifies its role in the analysis workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context on when to use the tool: 'Use this first to identify which functions are consuming the most CPU in a Node.js performance profile.' This indicates it is a starting point, but it does not explicitly mention when not to use it or name alternative tools. It therefore qualifies as clear context without exclusionary guidance, matching a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0analyze_async_bottlenecksanalyze_call_tree_pathanalyze_gc_pressurecorrelate_source_codediff_profilesextract_hottest_functionsScored across 6 tools
Each tool targets a distinct analytical question: extraction of hot functions, caller analysis, source mapping, GC pressure, profile diffing, and async bottleneck detection. There is no overlap in purpose; each description clearly identifies a unique use case.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (extract_hottest_functions, analyze_call_tree_path, etc.). The verbs are varied but the structure is uniform, making the set easy to scan and predict.
Six tools is well within the ideal range for a specialized server. Each tool covers a meaningful aspect of CPU profile analysis without redundancy or bloat, and the number feels appropriate for the server's scope.
The tool set covers the primary workflows for CPU profile analysis: identifying hot spots, tracing callers, mapping to source, GC overhead, before/after comparison, and async overhead. Minor gaps exist, such as a tool for basic profile metadata (total samples, duration), but the core diagnostic needs are met.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Analytics for MCP servers. Find out which of your tools agents get wrong. MCPulse shows you which tools AI agents retry, which come back empty, and which they never call at all. Two lines inside your own server. It never sees your arguments or your results. getmcpulse.com
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
The Polar Signals MCP server enables AI assistants to connect directly with performance profiling data, allowing users to analyze application performance through natural language queries. Key capabilities include querying CPU performance and memory usage, exploring profiling metadata like profile types and labels, and providing AI-driven code optimization suggestions directly within development environments like Claude Code or Cursor.
