io.github.vola-trebla/v8-cpu-profile-decoder-mcp

Est-ce que io.github.vola-trebla/v8-cpu-profile-decoder-mcp est sûr ?

Au dernier audit MCP Hub, le serveur MCP « io.github.vola-trebla/v8-cpu-profile-decoder-mcp » est classé « Vérifié ». Aucun comportement malveillant détecté au test comportemental. Le verdict est réévalué en continu ; consultez la fiche pour l'état à jour.

Méthode : MCP Hub analyse la description de chaque outil (couche 1) et, pour le verdict fort, exécute le serveur dans une micro-VM isolée avec leurres et réseau bloqué (couche 2). On publie des noms et des compteurs, jamais le contenu brut renvoyé par un outil.

Versions auditées & empreintes

Vérifiez la version que vous utilisez : son empreinte doit correspondre à celle listée ici — sinon vous n'utilisez pas la version auditée.

Vous utilisez ce serveur ? Suivez-le (créez un compte) pour être alerté dès qu'une nouvelle version paraît ou que le verdict change.

Les 6 outils

• extract_hottest_functions≈ 452 tokens

  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.

  Paramètres, retour & exemple (6)

  Paramètres

  • top_n · integer · optionnel
    Number of hottest functions to return (default: 10)
  • profile_path · string · requis
    Absolute path to the .cpuprofile file
  • min_self_percent · number · optionnel
    Minimum self time percentage to include a function (default: 0.5%)
  • collapse_recursion · boolean · optionnel
    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 · boolean · optionnel
    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 · boolean · optionnel
    Include V8 internals and Node.js built-ins in results (default: false)

  Exemple d'appel

  {"name": "extract_hottest_functions", "arguments": {"profile_path": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• analyze_call_tree_path≈ 197 tokens

  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?

  Paramètres, retour & exemple (3)

  Paramètres

  • top_callers · integer · optionnel
    Number of top callers to return (default: 5)
  • profile_path · string · requis
    Absolute path to the .cpuprofile file
  • function_name · string · requis
    Function name to search for (partial match, case-insensitive)

  Exemple d'appel

  {"name": "analyze_call_tree_path", "arguments": {"profile_path": "texte", "function_name": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• correlate_source_code≈ 210 tokens

  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?

  Paramètres, retour & exemple (3)

  Paramètres

  • top_n · integer · optionnel
    Number of hottest functions to resolve (default: 10)
  • profile_path · string · requis
    Absolute path to the .cpuprofile file
  • sourcemap_dir · string · optionnel
    Override directory to search for .map files (default: same directory as .js file)

  Exemple d'appel

  {"name": "correlate_source_code", "arguments": {"profile_path": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• analyze_gc_pressure≈ 230 tokens

  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?

  Paramètres, retour & exemple (2)

  Paramètres

  • profile_path · string · requis
    Absolute path to the .cpuprofile file
  • threshold_percent · number · optionnel
    GC percentage above which exceeds_threshold is set to true and a warning is emitted (default: 10)

  Exemple d'appel

  {"name": "analyze_gc_pressure", "arguments": {"profile_path": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• diff_profiles≈ 255 tokens

  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?

  Paramètres, retour & exemple (3)

  Paramètres

  • top_n · integer · optionnel
    Number of top improvements and regressions to return (default: 5)
  • after_profile_path · string · requis
    Absolute path to the optimized .cpuprofile file to compare against the baseline
  • before_profile_path · string · requis
    Absolute path to the baseline .cpuprofile file

  Exemple d'appel

  {"name": "diff_profiles", "arguments": {"after_profile_path": "texte", "before_profile_path": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

• analyze_async_bottlenecks≈ 222 tokens

  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?

  Paramètres, retour & exemple (2)

  Paramètres

  • profile_path · string · requis
    Absolute path to the .cpuprofile file
  • threshold_percent · number · optionnel
    Async overhead percentage above which a warning is emitted in the verdict (default: 10)

  Exemple d'appel

  {"name": "analyze_async_bottlenecks", "arguments": {"profile_path": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}]}

Badge pour votre README

Ce serveur a passé le pentest comportemental. Le badge porte son nom et renvoie à cette fiche — la preuve, c'est la fiche (verdict live qu'on contrôle), pas l'image.

[![Vérifié par MCP Hub](https://dokore.fr/badge/io.github.vola-trebla--v8-cpu-profile-decoder-mcp.svg)](https://dokore.fr/serveur/io.github.vola-trebla--v8-cpu-profile-decoder-mcp)

<a href="https://dokore.fr/serveur/io.github.vola-trebla--v8-cpu-profile-decoder-mcp"><img src="https://dokore.fr/badge/io.github.vola-trebla--v8-cpu-profile-decoder-mcp.svg" alt="Vérifié par MCP Hub" height="20"></a>

Réévalué en continu : si le comportement change, le verdict tombe et le badge disparaît. Un badge qui ne pointe pas vers une fiche dokore.fr ne prouve rien. Comment ça marche

C'est votre serveur ?

Revendiquez-le sur l'espace créateur (preuve GitHub, domaine ou npm) pour afficher le badge « propriétaire vérifié » et lancer un pentest comportemental à la demande afin d'obtenir le badge « Vérifié ».

Créer un compte / revendiquer →

Source

v8-cpu-profile-decoder-mcp@0.3.0